Брокер в программировании что это

Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры

Вы наверняка заметили тенденцию к усложнению программных систем: они становятся всё масштабнее и начинают состоять из множества отдельных компонентов. Внутри им как-то нужно взаимодействовать друг с другом, и способов для такой коммуникации придумано немало. Но особняком среди них стоят брокеры сообщений.

Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.

Брокер сообщений представляет собой тип построения архитектуры, при котором элементы системы «общаются» друг с другом с помощью посредника. Благодаря его работе происходит снятие нагрузки с веб-сервисов, так как им не приходится заниматься пересылкой сообщений: всю сопутствующую этому процессу работу он берёт на себя.

Можно сказать, что в работе любого брокера сообщений используются две основные сущности: producer (издатель сообщений) и consumer (потребитель/подписчик).

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

Здесь возможны несколько вариантов:

• Сообщение отправляется напрямую от отправителя к получателю.

В этом случае каждое сообщение используется только однократно;

• Схема публикации/подписки.

В рамках этой схемы обмена сообщениями отправитель не знает своих получателей и просто публикует сообщения в определённую тему. Потребители, которые подписаны на эту тему, получают сообщение. Далее на базе этой системы может быть построена работа с распределением задач между подписчиками. То есть выстроена логика работы, когда в одну и ту же тему публикуются сообщения для разных потребителей. Каждый «видит» уникальный маркер своего сообщения и забирает его для исполнения.

Для чего нужны брокеры сообщений?

• Для организации связи между отдельными службами, даже если какая-то из них не работает в данный момент. То есть продюсер может отправлять сообщения, несмотря на то, проявляет ли активность потребитель в настоящее время.
• За счёт асинхронной обработки задач можно увеличить производительность системы в целом.
• Для обеспечения надёжности доставки сообщений: как правило, брокеры обеспечивают механизмы многократной отправки сообщений в тот же момент или через определённое время. Кроме того, обеспечивается соответствующая маршрутизация сообщений, которые не были доставлены.

Недостатки брокеров сообщений:

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

Когда брокеры сообщений могут быть полезны:

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

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

• Мобильные приложения: здесь возможен вариант с задействованием push-уведомлений, когда множество смартфонов с установленным приложением подписаны на определённую тему. Если в ней публикуется какая-либо новость, то подписанный смартфон выводит уведомление.
• Транзакционные системы: если какое-то действие системы состоит из множества отдельных этапов, каждый из которых выполняется отдельным элементом системы, то в этом случае брокер сообщений может выступить в роли своеобразной «доски уведомлений». Каждый сервис отписывается после того, как его этап общей задачи был выполнен. После этого в работу вступает следующий сервис, обрабатывающий, соответственно, следующий этап общей задачи.

Какие есть брокеры сообщений?

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

Каждый из них обладает определёнными «фишками» и хорошо решает возложенные на него задачи. Например, если одни предназначены для создания инфраструктуры связи между распределёнными частями приложения, другие предназначены для достаточно специфических задач, например «интернета вещей», и функционируют на основе легковесного протокола MQTT. Подобные брокеры служат для сбора статистики, температуры и других показателей с распределённых датчиков, установленных на определённых машинах, элементах конструкций, географически разных точках территории.

Малое время задержки для прохода сообщения по сети, а также возможность двунаправленной связи в реальном времени (так как MQTT является надстройкой над дуплексным протоколом websockets) позволяют реализовывать достаточно интересные применения. Среди них может быть даже управление робототехническими устройствами в реальном времени. При таком управлении задержка не превышает десятков миллисекунд, что вполне допустимо для низкоскоростных устройств. Например, для управления роботами, движущимися в промышленных цехах и использующимися для перевозки деталей от станков или сырья к производственным станкам.

Также информационные системы на базе протокола MQTT используются в автомобильной сфере и в ряде других промышленных областей (HiveMQ).

Apache Kafka и RabbitMQ: что выбрать?

В корпоративных инфраструктурных системах популярностью пользуются Apache Kafka и RabbitMQ. В связи с чем часто возникает вопрос, какую из них выбрать в конкретном случае?

Говоря о RabbitMQ, можно сказать, что он представляет собой классический брокер, в котором присутствуют две описанные выше сущности – продюсер (система, генерирующая сообщения о разнообразных событиях) и подписчик, являющийся получателем этих сообщений.

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

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

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

В рамках этого брокера инициатором информационного обмена является продюсер, только он отправляет сообщение в сеть, в то время как подписчик не может запросить его сам (так называемая «push-доставка сообщений»).

Apache Kafka представляет собой брокер, который, в отличие от RabbitMQ, хранит все сообщения в виде распределённого лога, причём гарантируется, что порядок сообщений отражает последовательность их поступления в систему. Сообщение в этом логе хранится в течение определённого времени, и работа построена таким образом, что продюсеры пишут новые сообщения в систему, а подписчики сами их запрашивают. При надобности организуется хранение сообщений в рамках тем. То есть можно сказать, что происходит определённого рода группировка сообщений в рамках одной темы.

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

В свою очередь, брокер Apache Kafka больше предназначен для построения высоконагруженных систем сферы bigdata, так как сама его парадигма параллельной обработки, репликации позволяет создавать достаточно надёжные системы и обеспечивать неограниченные возможности по масштабированию. Высокая пропускная способность, а также возможности извлечения сообщений из очереди за определённый период времени (так как они хранятся в очереди, как мы сказали ранее, именно в том порядке, в каком были отправлены) являются мощным инструментом для анализа происходящего в историческом разрезе.

Platform V Corax

В экосистеме Сбера для приложений с микросервисной архитектурой есть также свой брокер сообщений.

Platform V Corax – программный продукт, предназначенный для автоматизации развёртывания, масштабирования контейнеризированных приложений и управления ими с использованием платформы Kubernetes путём предоставления REST API. Выполняет функции развёртывания, администрирования и учёта ресурсов инсталляций Kafka.

Platform V Corax – это платформа для работы с потоками данных, обладающая высокой производительностью и отказоустойчивостью. Разработана на базе открытого программного обеспечения Apache Kafka.

Она сохраняет рыночные преимущества свободно распространяемой версии Apache Kafka и имеет контролируемый и сокращённый релизный цикл по сравнению с open source-версией. Функциональность продукта соответствует запросам Enterprise-клиентов.

Система обеспечивает высокую скорость передачи сообщений и открывает возможность разработки новой функциональности по требованиям клиента, поддерживает транзакции и аудит изменения конфигурации кластера. Она также позволяет обеспечить повышенные требования к безопасности хранимых данных, обеспечивает контроль доступа через SASL и TLS-шифрование.

Пример использования Platform V Corax – непрерывная передача информации с конечных устройств в платформу. Данные не только передаются, но и обрабатываются множеством клиентов, которые называются подписчиками (consumers). В роли подписчиков могут выступать приложения и программные сервисы.

Преимущества:

• Горизонтальное масштабирование.
• Высокая скорость передачи сообщений.
• Поддержка транзакций.
• Контроль доступа через SASL.
• TLS-шифрование.
• Аудит изменения конфигурации кластера.

Platform V Corax поставляется вместе с UI-интерфейсом, реализующим все базовые элементы управления сервисом.

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

Выбирая нужный брокер, следует исходить из глубокого понимания вашей системы и её потребностей. Например, если нужно построение сложных сценариев маршрутизации, можно выбрать известный брокер RabbitMQ. Если же вы проектируете высоконагруженные системы, то советуем остановиться на Apache Kafka – он отлично справляется с этой задачей. А если у вас enterprise-разработка – отличным решением будет Platform V Corax.

• Блог компании Сбер
• IT-инфраструктура
• Сетевые технологии
• Микросервисы

Что такое Apache Kafka: как устроен и работает брокер сообщений

Apache Kafka — распределенный брокер сообщений, работающий в стриминговом режиме. В статье мы расскажем про его устройство и преимущества, а также о том, где применяют это ПО.

Apache Kafka — распределенный брокер сообщений, работающий в стриминговом режиме. В статье мы расскажем про его устройство и преимущества, а также о том, где применяют «Кафку».

Что такое брокер сообщений

Главная задача брокера — обеспечение связи и обмена информацией между приложениями или отдельными модулями в режиме реального времени.

Брокер — система, преобразующая сообщение от источника данных (продюсера) в сообщение принимающей стороны (консьюмера). Брокер выступает проводником и состоит из серверов, объединенных в кластеры.

Apache Kafka — диспетчер сообщений, разработанный LinkedIn. В 2011 году был опубликован программный код. В 2012 году Kafka попал в инкубатор Apache, дальнейшая разработка ведется в рамках Apache Software Foundation. Открытое программное обеспечение с разрешительной лицензией написано на Java и Scala.

Изначально «Кафку» создавали как систему, оптимизированную под запись, и создатель Джей Крепс выбрал такое название в честь одного из своих любимых писателей.

Шаги передачи данных

Чтобы понять, как функционирует распределенная система Apache Kafka, необходимо проследить путь данных.

Событие или сообщение — данные, которые поступают из одного сервиса, хранятся на узлах Kafka и читаются другими сервисами. Сообщение состоит из:

• Key — опциональный ключ, нужен для распределения сообщений по кластеру.
• Value — массив байт, бизнес-данные.
• Timestamp — текущее системное время, устанавливается отправителем или кластером во время обработки.
• Headers — пользовательские атрибуты key-value, которые прикрепляют к сообщению.

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

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

Какие сложности решает распределенная система

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

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

Managed service для Apache Kafka

Сообщения хранятся на узлах-брокерах. Kafka — масштабируемый кластер со множеством взаимозаменяемых серверов, в которые добавляются новые брокеры, распределяющие задачи между собой.

ZooKeeper — инструмент-координатор, действует как общая служба конфигурации в системе. Работает как база для хранения метаданных о состоянии узлов кластера и расположении сообщений. ZooKeeper обеспечивает гибкую и надежную синхронизацию в распределенной системе, позволяя нескольким клиентам выполнять одновременно чтение и запись.

Kafka Controller — среди брокеров Zookeeper выбирает одного, который будет обеспечивать консистентность данных.

Topic — принцип деления потока данных, базовая и основная сущность Apache Kafka. В топик складывается стрим данных, единая очередь из входящих сообщений.

Partition — для ускорения чтения и записи топики делятся на партиции. Происходит параллелизация данных. Это конфигурируемый параметр, сообщения могут отправлять несколько продюсеров и принимать несколько консьюмеров.

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

Преимущества Apache Kafka

Брокер распределяет информацию в широковещательном режиме. Применяющийся в Apache Kafka подход нужен для масштабирования и репликации данных.

Горизонтальное масштабирование

Множество объединенных серверов гарантируют высокую доступность данных — выход из строя одного из узлов не нарушает целостность. Кластер состоит из обычных машин, а не суперкомпьютеров, их можно менять и дополнять. Система автоматически перебалансируется.

Чтобы события не потерялись, существуют механизмы репликации. Данные записываются на несколько машин, если что-то случается с сервером, он переключается на резервный. Кластер в режиме реального времени определяет, где находятся данные, и продолжает их использовать.

Офсеты

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

Взаимодействие через API

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

Принцип first in — first out

Принцип FIFO действует на консьюмеров. Чтение происходит в том же порядке, в котором пришла информация.

Где применяется Apache Kafka

Отказоустойчивая система используется в бизнесе, где необходимо собирать, хранить и обрабатывать большие неструктурированные данные. Примеры — платформы, где требуется интеграция данных из большого количества источников, сервисы стриминговой аналитики, mission-critical applications.

Big Data

Первоначально LinkedIn разработали «Кафку» для своих целей: обмена данными между службами, репликации баз данных, потоковой передачи информации о деятельности и операционных показателях приложений.

Для IBM Apache Kafka работает как средство обмена сообщениями между микросервисами. В аналитических системах американской корпорации Apache Kafka обрабатывает потоковые и событийные данные.

Uber, Twitter, Netflix и AirBnb с помощью хорошо развитых пайплайнов обработки данных передают миллиарды сообщений в день. «Кафка» решает проблемы перемещения Big data из одного источника в другой.

Издание The New York Times использует Apache Kafka для хранения и распространения опубликованного контента среди различных приложений и систем, которые делают его доступным для читателей в режиме реального времени.

Internet of Things

IoT-платформы используют архитектуру с большим количеством конечных устройств: контроллеров, датчиков, сенсоров и smart-гаджетов. ПО интернета вещей с помощью алгоритмов ML составляет графики профилактического ремонта оборудования, анализируя данные, поступающие с устройств.

ML-системы работают с онлайн-потоками, когда приборы, приложения и пользователи постоянно посылают данные, а сервисы обрабатывают их в реальном времени. Apache Kafka выступает центральным звеном в этом процессе.

Отрасли

Kafka используют организации практически в любой отрасли: разработка ПО, финансовые услуги, здравоохранение, государственное управление, транспорт, телеком, геймдев.

Сегодня Kafka пользуются тысячи компаний, более 60% входят в список Fortune 100. На официальном сайте представлен полный список корпораций и учреждений, которые используют брокера Apache.

Конкуренты

Чаще всего Kafka сравнивают с RabbitMQ. Обе системы — брокеры сообщений. Главное отличие в модели доставки: Kafka добавляет сообщение в журнал, и консьюмер сам забирает информацию из топика; брокер RabbitMQ самостоятельно отправляет сообщения получателям — помещает событие в очередь и отслеживает его статус.

«Кролик» удаляет событие после доставки, «Кафка» хранит до запланированной очистки журнала. Таким образом, брокер Apache используется как источник истории изменений.

Разработчики RabbitMQ создали системы управления потоком сообщений: мониторинг получения, маршрутизация и шаблоны доставки. Подобное гибкое управление подойдет для высокоскоростного обмена сообщениями между несколькими сервисами. Минус такого подхода в снижении производительности при высокой нагрузке.

Главный вывод — для сбора и агрегации событий из большого количества источников, логов и метрик больше подойдет Apache Kafka.

Заключение

Благодаря высокой пропускной способности и согласованности данных Apache Kafka обрабатывает огромные массивы данных в реальном времени. Системы горизонтального масштабирования и офсеты гарантируют надежность. Kafka — удачное решение для проекта с очень большими нагрузками на обработку данных. Установить это ПО можно на серверы Ubuntu, Windows, CentOS и других популярных операционных систем.

Брокеры сообщений: зачем нужны и какой выбрать

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

Зачем нужны брокеры сообщений

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

При реализации синхронного взаимодействия вы должны учитывать несколько обстоятельств, при которых пункт назначения сервиса может быть недоступен или иметь низкую производительность, медленный отклик. Делать это необходимо, поскольку эти обстоятельства приведут к серьезным проблемам с производительностью вашего приложения. Для решения этих проблем можно использовать общение на основе сообщений. В этом помогут брокеры сообщений. С брокером сообщений связь будет асинхронной.

Какие бывают брокеры сообщений

Брокеров сообщений есть множество, но сегодня я хотел бы выделить два вида: Apache Kafka и RabbitMQ, так как они являются промышленными стандартами и используются во многих высоконагруженных системах. Apache Kafka и RabbitMQ — это две коммерчески поддерживаемые системы публикации и подписки с открытым исходным кодом, которые легко внедряются предприятиями. RabbitMQ — был выпущен в 2007 году. Он является основным компонентом систем обмена сообщениями и SOA. Среди областей его применения также потоковая передача. Kafka же был создан изначально для потоковых сценариев в 2011 году. Важным отличием Kafka от RabbitMQ является то, что первый основан на pull, а второй — на push. В чем суть? Системы, основанные на pull предполагают ожидание брокерами запроса данных со стороны потребителя — так называемое «вытягивание». Системы же базирующиеся на push-уведомлениях отправляют сообщения сразу всем подписанным потребителям. Это различие ведет к тому, что брокеры ведут себя по-разному. Так, Kafka допускает создание длинных пулов, что предотвращает зацикливание, когда нет сообщения после смещения, и агрессивно группирует сообщения для поддержки этого. Подобная модель является логичной для этого брокера сообщений из-за секционированной структуры данных. Kafka обеспечивает порядок сообщений в разделе без конкурирующих потребителей. Благодаря этому пользователи могут использовать пакетную обработку сообщений для их эффективной доставки и повышения пропускной способности.

Модель push-уведомлений RabbitMQ предотвращает перегрузку потребителей за счет ограничения предварительной выборки. Цель такого брокера сообщений заключается в индивидуальном распространение сообщений без задержек для обеспечения равномерной работы и обработки сообщений в порядке их поступления. Это может создать проблемы в случаях, когда потребители «умерли» и перестали получать сообщения.

Как внедрить брокеры сообщений

Давайте реализуем два приложения. Для простоты будем использовать spring cloud stream. Первое приложение будет публиковать сообщения о фильмах. Второе — слушать и складировать фильмы. Для начала добавим зависимости:

Нам также нужно запустить экземпляры Kafka. Есть несколько способов сделать это, но я предпочел бы запустить Kafka с помощью Docker compose. Для приложений будет общая модель:

Добавим контроллер для первого приложения:

Мы аннотируем наш класс контроллера с помощью @EnableBinding. Здесь мы делаем привязку к Source (публикующая сторона) и используем объект класса Source для публикации объекта Message в Apache Kafka. Добавим также файл с настройками:

Следующий шаг — указываем, что output — это наш Source у издателя (некий выходной канал). Отлично! Для второго приложения будем использовать ту же модель и добавим слой бизнес логики:

Тут также аннотируем наш класс с помощью @EnableBinding. Только уже делаем привязку к Sink (принимающая сторона). Файл с настройками будет выглядеть следующим образом:

Необходимо указать input — это входной канал у брокера Все готово. Теперь запускаем наши приложения и с помощью Postman добавляем фильм:

И видим сообщение об успешном добавлении фильма в топик:

Риски внедрения брокеров сообщений

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

Рекомендации по использованию

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

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

Брокер сообщений Redis — Основы Redis

Представьте, что вы пишете back-end интернет-магазина. Когда клиент оставляет заказ, сервер сохраняет данные в БД, отправляет чек клиенту на электронную почту и передает информацию в отдел обработки заказов. Самый простой способ реализовать этот алгоритм — выполнять все последовательно синхронно. Однако при разработке веб-приложений всегда стоит учитывать, что что-то может пойти не так. Провайдер электронных писем может иметь технические проблемы, из-за чего отправка письма задержится на несколько секунд или письмо не отправится с первого раза.

Допустим, провайдер электронных писем работает штатно, и выполнение алгоритма происходит дальше. Но теперь сервис обработки заказов недоступен по какой-то причине. И снова запрос зависает на несколько секунд или не отрабатывает вовсе.

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

Message Brokers

Асинхронную обработку обычно делают с помощью специальных сервисов — брокеров сообщений. Сегодня существует множество различных брокеров сообщений и каждый из них хорошо подходит под свои задачи. Концептуально работу брокера сообщений можно описать так:

1. Back-end сервис кладет сообщения в брокера
2. С другой стороны сервис-обработчик (worker) читает сообщения из брокера и как-то их обрабатывает
3. Сообщения внутри брокера буферизируются и формируется очередь. Если в один момент времени нужно записать 10 тыс. сообщений, они запишутся без задержки, а потом обработаются за какой-то промежуток времени

Redis Message Broker

Многие проекты используют Redis как брокер сообщений из-за простоты интеграции. Популярные фреймворки абстрагируют от разработчика внутреннюю реализацию очередей в Redis. Однако в некоторых языках (например, Golang) можно интегрироваться самому.

Простая реализация

Рассмотрим простую реализацию очереди в Redis на примере оформления заказа в интернет магазине. При оформлении заказ сохраняется в БД синхронно, после этого кладется сообщение в 2 очереди для отправки электронного письма и передачи заказа в сервис обработки. Каждая очередь является списком (Lists). Чтобы положить сообщение в конец очереди, используется команда rpush . С другой стороны сервисы-обработчики слушают очередь командой blpop .

Допустим, пользователь с ID 33 оставил заказ. В этом случае будут выполнены следующие команды:

'' (integer) 1 127.0.0.1:6379> rpush queue:order:processing '' (integer) 1 

Проверим, что сообщения успешно сохранились в списках:

-1 1) "\"user_id\":33,\"order_id\":12345>" 127.0.0.1:6379> lrange queue:order:processing 0 -1 1) "\"user_id\":33,\"order_id\":12345>" 

Сервисы обработчики слушают очередь с помощью команды blpop key [key . ] timeout :

) "queue:order:mail_notification" 2) "\"user_id\":33,\"order_id\":12345>" 127.0.0.1:6379> blpop queue:order:processing 10 1) "queue:order:processing" 2) "\"user_id\":33,\"order_id\":12345>" 

Команда blpop — это блокирующее чтение списка. Если список пуст, то выполнение программы блокируется до наступления таймаута, указанного в последнем аргументе в секундах. Если в списке есть элементы, то команда удалит самый левый элемент списка и вернет его. Удаление и чтение происходит атомарно, то есть при нескольких одновременных запросах не может быть ситуации, когда один элемент прочитался более 1 раза.

В такой схеме есть значимый изъян. Если сервис обработчик достанет сообщение из очереди и упадет, не до конца его обработав, то сообщение потеряется навсегда. Надеяться, что система всегда будет работать как задумано (happy path), не стоит.

Надежные очереди в Redis

Успешно обработать ситуации, когда сервис не до конца обрабатывает сообщение, можно с помощью команды blmove source destination LEFT|RIGHT LEFT|RIGHT timeout . Эта команда также блокирует выполнение при пустом списке. Если в списке есть элементы, то самый левый элемент списка возвращается, удаляется из списка source и сохраняется в запасном списке destination.

'' (integer) 1 127.0.0.1:6379> blmove queue:order:mail_notification queue:order:mail_notification:fallback LEFT RIGHT 10 "\"user_id\":33,\"order_id\":12345>" 

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

Ошибки инфраструктуры

Отметим один важный момент. Если по какой-то причине упадет сам Redis сервер, то данные за последние несколько секунд могут быть потеряны. Этого можно избежать специальной настройкой персистентности данных, которая понизит производительность. Всегда присутствует компромисс между пропускной способностью и надежностью хранения. Детальное изучение настроек Redis-сервера выходит за рамки данного курса, но при необходимости нужную информацию можно найти в интернете.

Резюме

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

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях: