2023-01-30 10:06:34
Всем привет!
В своем канале я всегда рассказывал только про синхронные интеграции -
пришла пора это исправить.
Сегодня поговорим об асинхронном способе обмена данными, который используется повсеместно. Как правило, в крупных системах нет такого, что используется только один подход, синхронный или асинхронный - они всегда комбинируются,
т.к. у каждого есть свои преимущества и недостатки, и области использования, соответственно.
В тех местах, где нам нужно наладить интеграцию, достичь максимальной ее скорости, и, при этом, есть возможность пренебречь каким-то процентом потерянных пакетов данных, в случае обрыва соединения - применяют синхронную интеграцию (как минимум это
front-to-back интеграция, потому что мы всегда может попросить пользователя тыкнуть на кнопку еще раз).
В остальных случаях, когда мы можем немного пренебречь скоростью (хотя асинхронный обмен не настолько медленнее, как кажется) и при этом получить
функцию гарантированной доставки сообщений - применяют асинхронную интеграцию.
В основном, для асихнрона используется либо open-source решение
Apache Kafka, либо
RabbitMQ. Есть ряд других решений, но эти наиболее популярные на моей практике
и именно они чаще всего используются в ФинТехе. И среди этих двух решений, чаще я видел Kafka, особенно в банках - и это не просто так. Давайте с ней и разберемся.
Kafka состоит из трех компонентов:
1) Сервер (или по-другому брокер сообщений);
2) Продьюсер - источник данных, та система, которая посылает сообщения в брокер;
3) Консьюмер - потребитель данных, та система, которая получает данные из брокера.
А теперь приведу ту особенность Kafka, из-за которой ее так любят использовать банки -
сообщения не удаляются брокерами после их обработки консьюмерами, данные могут хранится днями, неделями (хоть годами), в зависимости от настроек.
И именно благодаря этому одно и тоже сообщение может быть обработано сколько угодно раз разными косьюмерами. Также это
позволяет восстановить все данные, находящиеся у брокера, в случае их утраты консьюмером уже после получения, даже спустя длительное время.
Как происходит сам процесс передачи сообщения:
Создается именованный топик, который по сути является точкой интеграции между Продьюсером и Консьюмером;
Продьюсер отправляет сообщение на сервер (в тот самый топик);
Консьюмер пытается забрать сообщение и его уникальный идентификатор, присовенный сервером;
Сервер помечает сообщение как in-flight и в этом состоянии оно всё еще хранится на сервере;
Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет ответ запрос обратно на сервер, используя его уникальный идентификатор и сообщает брокеру либо об успешной обработке, либо об ошибке;
В случае успеха сообщение помечается как прочитанное и больше не доступно для получения консьюмерами при стандартных запросах (только по требованию, если необходимо восстановить данные, или использовать его как-то еще). В случае ошибки сообщение будет получено консьюмером при следующем запросе.
Таким образом обспечивается гарантированная доставка сообщений. Даже если не получится забрать сообщение 10 раз, с какого-то раза
оно всё равно доставится (если, конечно, нет проблем в самом сообщении и его структуре, а не с сетью. Тогда это проблема на стороне Продьюсера).
Также Kafka имеет следующие преимущества:
Механизм, которые не позволяет читать одни и те же сообщения консьюмеру, даже в случае перезапуска его или самого брокера.
Если есть необходимость продьюсеру доставить одно сообщение сразу нескольким консьюмерам, то в отличие от других очередей - нет необходимости на каждого консьюмера постить по сообщению. Продьюсер посылает в брокер всего одно сообщение, из которого несколько консьюмеров уже сами его забирают.
Кроме этого есть множество других интересных настроек и возможностей, например встроенные балансировщики и прочие механизмы распределения нагрузки. На выходе получается очень мощное и гибкое решение, которое очень бережно обращается с данными и позволяет забыть о тревогах, связанных с их потерей.
262 views07:06
К
