Брокер сообщений Redis — Основы Redis
Представьте, что вы пишете back-end интернет-магазина. Когда клиент оставляет заказ, сервер сохраняет данные в БД, отправляет чек клиенту на электронную почту и передает информацию в отдел обработки заказов. Самый простой способ реализовать этот алгоритм — выполнять все последовательно синхронно. Однако при разработке веб-приложений всегда стоит учитывать, что что-то может пойти не так. Провайдер электронных писем может иметь технические проблемы, из-за чего отправка письма задержится на несколько секунд или письмо не отправится с первого раза.
Допустим, провайдер электронных писем работает штатно, и выполнение алгоритма происходит дальше. Но теперь сервис обработки заказов недоступен по какой-то причине. И снова запрос зависает на несколько секунд или не отрабатывает вовсе.
Должен ли пользователь долго ждать или видеть ошибки в случае временных технических неполадок со стороны третьих сервисов? Вряд ли. В правильной архитектуре запросы выполняются за десятки миллисекунд, а временные технические неполадки скрываются. Реализовать такую архитектуру можно с помощью асинхронной обработки отложенных задач.
Message Brokers
Асинхронную обработку обычно делают с помощью специальных сервисов — брокеров сообщений. Сегодня существует множество различных брокеров сообщений и каждый из них хорошо подходит под свои задачи. Концептуально работу брокера сообщений можно описать так:
- Back-end сервис кладет сообщения в брокера
- С другой стороны сервис-обработчик (worker) читает сообщения из брокера и как-то их обрабатывает
- Сообщения внутри брокера буферизируются и формируется очередь. Если в один момент времени нужно записать 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 студентов
Наши выпускники работают в компаниях:
Брокер в программировании что это
Думаю, все уже слышали и не раз про брокер сообщений Rabbit MQ. Давайте разберёмся, что это за зверь и какую нишу он может занять в инфраструктуре 1С.
Прежде всего нужно разобраться, что такое «брокер сообщений». Википедия говорит:
Брокер сообщений — архитектурный паттерн в распределённых системах. Приложение, которое преобразует сообщение по одному протоколу от приложения-источника в сообщение протокола приложения-приёмника, тем самым выступая между ними посредником.
Но если сказать простыми словами, брокер сообщения это сервис, который умеет принимать сообщения от клиента, хранить их и передавать их другому клиенту.
По сути, почтовый сервер также можно назвать брокером сообщений, и FTP сервер, и даже расшаренная папка на сервере может выступать посредником передачи сообщений.
Только когда в качестве брокера будет выступать такой примитивный сервис, как почтовый или FTP, то ряд вспомогательных функций — удаление сообщений после прочтения, определение очерёдности чтения, подтверждение получения сообщения и другие — будут ложиться на клиента. А полноценный брокер сообщений, например, Rabbit MQ все это берет на себя и предлагает ряд других возможностей, например, очередь и маршрутизацию.
Почему брокеры сообщений получили такое сильное распространение
На рынке есть много разных платформ, разработанных на разных языках программирования, и задача реализации обмена между разными системами достаточно сложная и затратная. По этой причине спрос создал потребность в сторонних сервисах, которые бы выступали посредниками и имели хорошо документированное API для реализации отправки и чтения сообщений. Я думаю, для всех более-менее известных языков программирования и фреймворков существуют готовые библиотеки для взаимодействия с Rabbit MQ. Разработчики по умолчанию выбирают этого брокера сообщений в своих проектах.
Как обстоит дело с Rabbit MQ в 1С
Есть 2 варианта:
- Использовать внешнюю Native API компоненту.
- Использовать HTTP API.
Особенности работы через HTTP API
Rabbit MQ хоть и имеет HTTP API, оно больше предназначено для администрирования сервиса, чем для обмена, имеет ряд ограничений (например, не поддерживает подтверждение принятия каждого сообщения ack) и работает достаточно медленно. В отзывах пишут, что бывают потери сообщений. Используют это решение мало, но есть примеры успешной реализации, например описанные здесь https://infostart.ru/1c/tools/1731834/.
Из плюсов — простота реализации и отсутствие внешних компонент.
Для более продвинутого варианта остаётся только использовать внешние библиотеки. На данный момент мне известно 2 основных решения:
- PinkRabbitMQ от BIT:ERP, бесплатно доступна на GITHUB https://github.com/BITERP/PinkRabbitMQ
- Интеграция от Серебряной пули (платная) https://silverbulleters.org/rabbitmq
- Есть также разные решения, размещенные на Infostart, например, описанные в статье https://infostart.ru/1c/tools/845345/.
Установка Rabbit MQ для тестирования обмена
Наверное, установка такой системы, как Rabbit MQ, могла быть нетривиальной задачей. Хотя, надо сказать, документация на сайте очень хорошая, хоть и англоязычная: https://www.rabbitmq.com/download.html
Но есть вариант гораздо проще и быстрее — развернуть готовый docker контейнер. Так и поступим. Изначально должен быть установлен сам Docker. Это тоже не проблема, есть клиент под Windows с интуитивно понятным интерфейсом: https://www.docker.com/products/docker-desktop/
После установки Docker, перезагрузки и возможно обновления подсистемы WSL (все инструкции даст сам Docker) достаточно открыть терминал и выполнить команду:
docker run -d —name rabbitmq -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=rabbit -e RABBITMQ_DEFAULT_PASS=rabbit rabbitmq:3.12-management
Обратите внимание, здесь есть небольшая модификация, я задал пользователя и пароль для сервиса. Так удобнее работать. Пароль по умолчанию был guest.
Сразу оставлю небольшую справку, по работе с контейнером:
1. Чтобы остановить контейнер необходимо выполнить:
docker stop rabbitmq
2. Чтобы запустить:
docker start rabbitmq
3. Чтобы удалить:
docker rm rabbitmq
Можно управлять контейнером и через интерфейс программы Docker-desktop.
После установки можно сразу открыть страницу управления Rabbit MQ по адресу http://localhost:15672 
А после логина мы попадаем в основной окно Rabbit MQ
Никаких настроек пока делать не будем и перейдём к реализации обмена в 1С. А процессе станет понятно, какие настройки понадобятся.
Отправка сообщений в Rabbit MQ из 1С
Я буду использовать решение PinkRabbitMQ от BIT:ERP. Первое, нам потребуется библиотека, которую можно скачать с GITHUB https://github.com/BITERP/PinkRabbitMQ/releases/tag/addins_PinkRabbitMQ_149.
В релизах есть несколько версий, чтобы в одной базе можно было подключить несколько экземпляров одной библиотеки для разных обменов.
Скачанный архив я поместил в общий макет. Подключить компоненту можно командой
Подключено = Ждать ПодключитьВнешнююКомпонентуАсинх(«ОбщийМакет.PinkRabbitMQ», «BITERP», ТипВнешнейКомпоненты.Native);
Не буду заострять внимание на подключении, пример можно посмотреть в синтакс-помощнике 1С.
Более интересен процесс отправки и получения сообщений. Отправка сообщений осуществляется методом BasicPublish. Но перед этим следует установить соединение с сервисом Rabbit MQ методом Connect .
Компонента = Ждать RebbitMQКлиент.ПолучитьКомпоненту();
Компонента.Connect(«localhost», 5672, «rabbit», «rabbit», «/»);
Компонента.BasicPublish(«», ИмяОчереди, ОтправляемоеСообщение, 0, Ложь );
Для подключения нам необходимо знать адрес сервиса, порт, пользователя и пароль. Все это было задано в момент установки Rabbit MQ. Для того чтобы отправить или получить сообщения, нужно знать Exchanges (имя точки обмена) и Queues (имя очереди), их мы и передаём в методе BasicPublish . Настроить их проще всего через интерфейс сервиса, но, если требуется, библиотека позволяет создать их программно.
На странице Exchanges добавим точку обмена.
А на странице Queues and Streams добавим очередь.
Ещё есть параметр Virtual host (виртуальный хост), по умолчанию он равен «/» и, как правило, не меняется.
После этих настроек можно выполнить код, описанный выше.
Получение сообщений
Получение сообщений происходит методом BasicConsumeMessage . Но перед его вызовом ещё требуется использовать метод BasicConsume , который начинает чтение и регистрирует потребителя сообщений для очереди. Для чтения достаточно знать только имя очереди.
НеЖдать = Ложь; //noConfirm
Компонента = Ждать RebbitMQКлиент.ПолучитьКомпоненту();
Компонента.Connect(«localhost», 5672, «rabbit», «rabbit», «/»);
Потребитель = Компонента.BasicConsume(ИмяОчереди, «», НеЖдать, Ложь, 0);
Если Компонента.BasicConsumeMessage(«», ОтветноеСообщение, ТегСообщения, 100) Тогда
Сообщить(«Успешно! Из очереди прочитано сообщение » + ОтветноеСообщение);
Обратите внимание ещё на один метод BasicAck . Он отсылает серверу подтверждение (ack), что сообщение обработано и его можно удалить.
Это метод работает вместе с параметром noConfirm , который указывает сервису очищать очередь после прочтения любого сообщения или ждать ответ методом BasicAck.
Т.е. если noConfirm установить в значение Истина, очередь будет автоматически очищаться. В таком случае нам нужно сразу читать все сообщения.
Если мы отказываемся от автоматической очистки очереди, то с помощью метода BasicAck мы можем подтвердить прочтение сообщения и только после этого оно будет удалено. Переменная ТегСообщения , которая устанавливается в методе BasicConsumeMessage , содержит номер прочитанного сообщения. Он передаётся в метод BasicAck.
Здесь я описал минимум, который достаточен, чтобы организовать обмен с брокером сообщений Rabbit MQ.
Пример реализации обмена выложен на GitHUB. Можно клонировать проект по адресу git@github.com:free-archer/RabbitMQ_Simle.git и развернуть в EDT, а можно просто скачать выгрузку конфигурации и базы https://github.com/free-archer/RabbitMQ_Simle/releases/tag/v1.0.
В конфигурации реализован пример работы с Rabbit MQ на клиенте и на сервере. Настройки подключения хранятся в регистре. Это позволяет легко настроить подключения и проверить работоспособность сервиса.
Заключение
Хочется вернуться к вопросу, который я обозначил вначале, и понять, какую нишу брокеры сообщений занимают в инфраструктуре 1С.
Если 1С обменивается со сторонними системами, разработанными не на платформе 1С, выбор брокера сообщений, скорее всего, будет продиктован разработчиками этой системы. И Rabbit MQ может быть выбран как самый популярный и проверенный временем брокер.
Но нужен ли брокер, если обмен строится между системами, разработанными на платформе 1С? Вопрос не простой. По моему мнению, с обменом большими порциями данных лучше справится типовой обмен БСП по технологии КД2 или КД3. И применение брокера сообщений не даст особых преимуществ, а только усложнит систему.
Что такое 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 и других популярных операционных систем.
Kafka Apache
Kafka Apache — распределенная система обмена сообщениями между серверными приложениями в режиме реального времени. Благодаря высокой пропускной способности, масштабируемости и надежности применяется в компаниях, работающих с большими объемами данных. Написана на языках Java и Scala.
Освойте профессию
«Fullstack-разработчик на Python»
Kafka разработана компанией LinkedIn. В 2011 году разработчик опубликовал исходный код системы. С тех пор платформа развивается и поддерживается как открытый проект в рамках фонда Apache Software Foundation. Apache Kafka используют многие крупные компании, такие как LinkedIn, Microsoft, The New York Times, Netflix и другие.
Профессия / 12 месяцев
Fullstack-разработчик на Python
Создавайте веб-проекты самостоятельно
Применение Kafka Apache
Kafka Apache — эффективный инструмент для организации работы серверных проектов любого уровня. Благодаря гибкости, масштабируемости и отказоустойчивости используется в различных направлениях IT-индустрии, от сервисов потоковых видео до аналитики Big Data.
- Для связи микросервисов. Kafka — связующее звено между отдельными функциональными модулями большой системы. Например, с ее помощью можно подписать микросервис на другие компоненты для регулярного получения обновлений.
- Потоковая передача данных. Высокая пропускная способность системы позволяет поддерживать непрерывные потоки информации. За счет грамотной маршрутизации «Кафка» не только надежно передает данные, но и позволяет производить с ними различные операции.
- Ведение журнала событий. Kafka сохраняет данные в строго организованную структуру, в которой всегда можно отследить, когда произошло то или иное событие. Информация хранится в течение заданного промежутка времени, что можно использовать для разгрузки базы данных или медленно работающих систем логирования.
Читайте также Как выбрать IT-специальность в новых реалиях?
Как устроена и работает Kafka Apache
Кратко архитектуру системы сообщений можно охарактеризовать следующим образом:
- распределенность — отдельные узлы системы располагаются на нескольких аппаратных платформах (кластерах). Это обеспечивает ей высокую отказоустойчивость;
- масштабируемость — систему можно наращивать за счет простого добавления новых узлов (брокеров сообщений).
В архитектуре Kafka Apache ключевыми являются концепции:
- продюсер (producer) — приложение или процесс, генерирующий и посылающий данные (публикующий сообщение);
- потребитель (consumer)— приложение или процесс, который принимает сгенерированное продюсером сообщение;
- сообщение — пакет данных, необходимый для совершения какой-либо операции (например, авторизации, оформления покупки или подписки);
- брокер — узел (диспетчер) передачи сообщения от процесса-продюсера приложению-потребителю;
- топик (тема)— виртуальное хранилище сообщений (журнал записей) одинакового или похожего содержания, из которого приложение-потребитель извлекает необходимую ему информацию.
В упрощенном виде работа Kafka Apache выглядит следующим образом:
- Приложение-продюсер создает сообщение и отправляет его на узел Kafka.
- Брокер сохраняет сообщение в топике, на который подписаны приложения-потребители.
- Потребитель при необходимости делает запрос в топик и получает из него нужные данные.
Сообщения хранятся в Kafka в виде журнала коммитов — записей, размещенных в строгой последовательности. Их можно только добавлять. Удалять или корректировать нельзя. Сообщения хранятся в той последовательности, в которой поступили, их считывание ведется слева направо, а отслеживание — по изменению порядкового номера. Брокеры Kafka не обрабатывают записи — только помещают их в тему на кластере. Хранение может длиться в течение определенного периода или до достижения заданного порога.
Станьте Fullstack-разработчик на Python и найдите стабильную работу
на удаленке
Если тема слишком разрастается, для упрощения и ускорения процесса она разделяется на секции. Каждая секция содержит сообщения, сгруппированные по объединяющему признаку. Например, массив пользовательских запросов можно сгруппировать по первой букве имени пользователей. Так приложению-потребителю не придется просматривать весь топик — только нужную тему, что ускоряет процесс обмена сообщениями.
Преимущества Kafka
Отказоустойчивость
Kafka — распределенная система обмена сообщениями, узлы которой содержатся на нескольких кластерах. Принимая сообщение от продюсера, она реплицирует (копирует) его, а копии сохраняет на разных узлах. При этом один из брокеров назначается ведомым в секции, через него потребители будут обращаться к записям. Другие брокеры остаются ведомыми, их главная задача — обеспечить сохранность сообщения (его копий) даже при выходе одного или нескольких узлов из строя. Распределенный характер и механизм репликации записей обеспечивают системе высокую устойчивость. Надежность повышает интеграция с Apache ZooKeeper, которая обеспечивает координацию компонентов друг с другом.
Масштабируемость
Apache Kafka поддерживает «горячее» расширение, то есть ее можно увеличивать с помощью простого добавления новых машин в кластеры, не отключая всю систему. Так исключаются простои, связанные с переоборудованием серверных мощностей. Принцип удобнее горизонтального масштабирования, при котором на одну серверную машину «навешиваются» дополнительные ресурсы: жесткие диски, CPU, RAM и т.д. При необходимости систему можно легко сократить, исключив лишние машины из кластера.
Производительность
В Kafka процессы генерирования/отправки и считывания сообщений организованы независимо друг от друга. Тысячи приложений, процессов могут одновременно и параллельно играть роль генераторов и потребителей сообщений. В сочетании с распределенным характером и масштабируемостью это позволяет применять «Кафка» как в небольших, так и в масштабных проектах с большими объемами данных.
Открытый исходный код
Kafka распространяется по свободной лицензии фонда Apache Software Foundation. Благодаря этому Kafka Apache имеет ряд преимуществ:
- большой объем подробной справочной информации от официальных разработчиков, а также различных мануалов, лайфхаков, инструкций и обзоров от большого числа энтузиастов-любителей и профессионалов;
- большое количество дополнительных программных пакетов, патчей от сторонних разработчиков, расширяющих и улучшающих базовый функционал системы;
- возможность самостоятельно адаптировать систему под специфику проекта за счет гибкости настроек.
Безопасность
В Kafka есть инструменты, обеспечивающие безопасную работу и достоверность данных. Например, настроив уровень изоляции для транзакций, можно исключить чтение незавершенных или отмененных сообщений. Кроме того, благодаря сохранению данных в топиках пользователь может в любой момент отследить изменения в системе. А принцип последовательной записи позволяет быстро находить нужные сообщения.
Долговечность
Данные в Kafka сохраняются в долговременные виртуальные хранилища в течение заданного периода времени (дней, недель, месяцев). За счет распределенного хранения информации она не потеряется при сбое одного или нескольких узлов, и потребитель сможет в любой момент обратиться к нужному сообщению в топике, отследив его смещение.
Интегрируемость
Благодаря собственному протоколу на базе TCP «Кафка Апач» взаимодействует с другими протоколами передачи данных (REST, HTTP, XMPP, STOMP, AMQP, MQTT). Встроенный фреймворк Kafka Connect позволяет Kafka подключаться к базам данных, файловым и облачным хранилищам.
Единственный заметный недостаток системы — ориентированность на обработку больших объемов данных. Из-за этого функционал маршрутизации потоков ограничен по сравнению с другими аналогичными платформами. По мере развития Kafka это различие становится менее заметным, а сама система — более гибкой и универсальной.
Fullstack-разработчик на Python
Fullstack-разработчики могут в одиночку сделать IT-проект от архитектуры до интерфейса. Их навыки востребованы у работодателей, особенно в стартапах. Научитесь программировать на Python и JavaScript и создавайте сервисы с нуля.