Очереди сообщений и протокол AMQP // Курс «RabbitMQ для разработчиков и администраторов»

• Максим, системный архитектор, рассказывает о очередях сообщений и их использовании в информационных технологиях.  

• Он работает в компании "Джайл" с 1991 года и имеет опыт работы в различных сферах, включая розничную торговлю, операторов связи, торговлю автозапчастями, автосервис, компанию "Оракол" и "Юзергейт".  

• Максим преподает курс для разработчиков и администраторов, который стартует в конце февраля.  

• Максим объясняет, что цель вебинара - понять, для чего используются очереди сообщений, их преимущества и недостатки, а также как работает протокол МКП.  

• Он также обсуждает, как очереди сообщений могут быть использованы для реализации различных сценариев и как знание протокола МКП может помочь в этом.  

• Максим приводит пример использования очередей сообщений в небольшой компании, которая решает создать сервис регистрации клиентов.  

• Он объясняет, что решение использовать очереди сообщений решает некоторые проблемы, такие как сильная связанность и масштабируемость, но также создает новые проблемы, такие как необходимость знать адреса сервисов и способы аутентификации.  

• Он также упоминает, что современные программы, такие как ESD и Hashi Consul, могут помочь решить эти проблемы.  

• Если сервисы взаимодействуют синхронно, то задержка в обработке запроса может вызвать задержку на ответе клиенту.  

• Переход на асинхронное взаимодействие может решить эту проблему.  

• Брокер позволяет организовать взаимодействие между сервисами через посредника.  

• Брокер сохраняет сообщения, не доставленные из-за падения сервиса.  

• Брокер может быть настроен на работу с разными сервисами, такими как Redis, Kafka и RabbitMQ.  

• Брокер позволяет добавлять новую функциональность без изменения кода сервиса.  

• Брокер может использоваться для организации сложных систем зависимостей между сервисами.  

• Брокер позволяет лучше отслеживать коммуникации между сервисами и может быть настроен на работу с очередью сообщений.  

• Брокеры используются для обеспечения взаимодействия между сервисами, минимизируя зацепление и обеспечивая слабую зависимость.  

• Брокеры также могут использоваться для решения проблемы неустойчивых каналов связи, например, через федерацию.  

• Брокер может быть единой точкой отказа, но это решается кластеризацией, федерацией и другими техническими ухищрениями.  

• Брокер также может усложнить поддержку, но это можно решить с помощью административных мер и написания взаимодействий между сервисами.  

• Брокеры не стоит использовать в простых сценариях и монолитных инфраструктурах, так как это может увеличить сложность поддержки.  

• Размер очереди может быть ограничен объемом оперативной памяти, и если очередь начинает заполняться, это может привести к проблемам.  

• Автор обсуждает использование очереди и протокола МКП, взвешивая плюсы и минусы каждого решения.  

• Он упоминает возможность использования негативной оконной лодгинга и механизма подтверждений для обработки ошибок.  

• Автор обсуждает протокол МКП, который является открытым протоколом для синхронного обмена сообщениями.  

• Он упоминает две версии протокола: МКП 0.9.1 и 1.0, и объясняет, что в основном все, что будет изучаться, будет связано с МКП 0.9.1.  

• Автор объясняет модель протокола МКП, где паблишер строит соединение с брокером и отправляет сообщения либо в очередь, либо напрямую.  

• Он также объясняет, что очереди связываются с брокером через бандинги, которые могут иметь свои собственные параметры.  

• Консьюмеры подключаются к очередям по протоколу МКП и могут забирать сообщения без подтверждения.  

• Создание соединения - дорогая процедура, поэтому лучше создавать несколько каналов внутри одного соединения.  

• В каждом канале работает RPC, где сторона один вызывает метод на стороне два.  

• В случае ошибки по умолчанию, канал закрывается.  

• Фреймы: тип фрейма, номер канала, длина, пилот.  

• Пропертис: информация о том, как сообщение должно жить и передаваться.  

• Метод фрейм: класс, метод, параметры, манда три флаг.  

• Очередь: один процесс с памятью, где сообщения сохраняются.  

• Экспишн: если сообщение не забрано до определенного времени, оно будет выкинуто.  

• Деливери мод: сохранение на диск для гарантии восстановления сообщений при перезапуске брокера.  

• Типы сообщений: фак директор ченч, бинарные данные.  

• Ограничение на размер сообщения: 27 МБ на одном сообщении.  

• Возможность использования бинарных данных для передачи небольших сообщений.  

• В протоколе MQ есть различные виды очередей, такие как топики, роутин кей и другие.  

• Звездочка и решетка используются для разделения роутин кей на слова.  

• Хедер совешен позволяет отправлять сообщения в разные очереди.  

• Типичный обмен сообщениями в протоколе MQ выглядит так: клиент говорит "декларируем очередь", сервер вызывает функцию на стороне клиента, и клиент отправляет фрейм с командой.  

• MQ имеет механизм подтверждения отправки сообщений, называемый паблише конфес.  

• Есть механизм негативного подтверждения, который позволяет получать подтверждение о публикации сообщения.  

• MQ также имеет механизм натификации из брокеров клиента, который позволяет получать сообщения, если соединение заблокировано.  

• MQ поддерживает приоритеты потребителей, что позволяет отправлять большую часть сообщений определенным потребителям.  

• MQ также имеет механизм директ реплай, который позволяет отправлять сообщения в определенную очередь, даже если она не создана.  

• MQ поддерживает ограничение на длину очереди и очереди с приоритетом, где часть сообщений может доставляться раньше других.  

• В видео обсуждается использование очередей в RabbitMQ, их преимущества и недостатки.  

• Упоминается, что RabbitMQ поддерживает кластеризацию и изотерические варианты.  

• В курсе по администрированию и программированию с помощью RabbitMQ, который открывается 28 февраля, будут рассмотрены вопросы кластеризации, федерация, конфигурирование RabbitMQ с помощью инструментов Diop и развертывание RabbitMQ в различных конфигурациях.  

• Вебинар был проведен для того, чтобы познакомить слушателей с преимуществами использования очередей, их работой и протоколами.  

• В ходе вебинара были рассмотрены различные сценарии использования очередей сообщений и их масштабируемость.  

• В видео обсуждаются различные способы мониторинга RabbitMQ, включая использование менеджмента, плагинов и консоли.  

• Упоминается, что для получения дополнительной информации о состоянии RabbitMQ можно использовать ирландскую консоль, но это требует определенных знаний и навыков.  

• В видео обсуждается идея создания очередей и потребителей, где продюсер создает ченч, а консьюмеры подключаются и слушают только то, что им нужно.  

• Обсуждаются различные варианты создания очередей и бандингов к ним.  

• Отвечая на вопросы, спикер обсуждает, как можно использовать одну очередь для нескольких консьюмеров, когда они могут забирать задания из одной очереди.  

• Спикер также обсуждает, что под заданием понимается отправка сообщения, содержащего всю необходимую информацию для выполнения задания.  

• Спикер обсуждает, как ускорение забора может быть связано с количеством сообщений в секунду и количеством байт, необходимых для выполнения задания.  

• Спикер также обсуждает, что оптимальное значение префикейта зависит от семантики консьюмера и его потребностей.