Очередь за кроликом
Недавно в проекте понадобилось использовать такой механизм, который позволял бы практически мгновенно сохранять данные, которые приходят пакетами в большом количестве. Поэтому было принято решение использовать очереди сообщений.
Message queue
Это такая архитектура, которая позволяет собирать, хранить и маршрутизировать данные.
Один из сервисов, которые позволяют реализовать такую архитектуру — это RabbitMQ. К слову сказать, что он один из самых популярных. И чисто технически он является брокером сообщений (или менеджером сообщений — кому как приятнее звучит:).
Менеджер сообщений — это такое ПО, которое позволяет создавать очереди и работать с клиентами, подключенными к этим очередям и пытающимися получить сообщения, хранящиеся в очереди. Почти совсем как обычный менеджер.
Данные в сообщениях могут быть абсолютно любыми: начиная от простого текста, заканчивая сложными бинарниками. Они хранятся в очереди до тех пор, пока с ними клиент не произведет действия.
RabbitMQ
Принцип работы брокера довольно простой. Есть три составляющие:
- поставщик (producer),
- очередь (queue) и
- подписчик (consumer).
Поставщик и подписчик подключаются к очереди, но работают с ней по-разному. Первый просто складывает туда данные, а второй их сначала ожидает, а потом читает. Поэтому очередь является таким связующим звеном между двумя точками.
Возникает вопрос: зачем её вообще использовать и городить дополнительное звено, которое может упасть и остановить всю работу? Ответ довольно простой: потому что подписчик может не успевать обрабатывать то количество данных, которое производит поставщик, и половина (если не больше) данных могут просто-напросто потеряться. Запись в очередь же происходит мгновенно, и данные оттуда просто так никуда не деваются (только если очередь не удалить:).
Exchange
На самом деле когда поставщик присылает данные, то они не сразу попадают в очередь. Сначала все сообщения приходят в одну из точек доступа (exchange). А уже из неё — в очередь, из которой подписчик может их прочитать.
В брокере может существовать несколько точек доступа. А в одной точке доступа может быть несколько очередей.
Есть несколько типов точек доступа:
- прямые (direct)
- множественные (fanout)
- обратные (topic)
- заголовочные (header)
- Точки доступа типа direct работают по принципу привязки по ключу. У сообщения есть routing key, а у очереди — binding key. Сообщения доставляются только в ту очередь, с которой точь-в-точь совпадают ключи.
- Точки доступа типа fanout отправляют сообщения во все очереди, которые созданы в этой точке. К слову сказать, если в direct exchange создать несколько разных очередей с одинаковым ключом, то они будут работать по принципу fanout: сообщения, у которых routing key будет совпадать, будут приходить во все очереди с таким же binding key.
- Точки доступа типа topic проверяют специальные символы между ключом сообщения и шаблоном (routing pattern), который участвует в привязке очереди.
- Точки доступа типа header для маршрутизации используют атрибуты в заголовках сообщений.
Lifecycle
С основными понятиями разобрались, теперь необходимо узнать, как ведет себя сообщение на всех этапах: начиная от отправки поставщиком, заканчивая удалением из очереди.
- Поставщик создает сообщение и отправляет его брокеру сообщений. Этот процесс называется публикацией (publish).
- Сообщение попадает в точку доступа, в которую его отправили.
- Дальше происходит привязка по routing key определенным типом точки доступа способом.
- Сообщение попадает в очередь, где остается дожидаться взаимодействия с подписчиком.
- Подписчик получает и обрабатывает сообщение из очереди. Этот процесс называется приемом (consume).
Теперь когда мы понимаем в теории, как работает брокер очередей, можно рассмотреть практические примеры.
Картинки взяты из блога CloudAMQP разработчика Lovisa Johansson.