Подтвердить что ты не робот

Создание системы push-уведомлений в реальном времени для настольных/мобильных/веб-приложений с использованием kafka в качестве брокера сообщений

У меня есть прецедент, где нужно быть в режиме реального времени связь между серверами и клиентами после pub/sub шаблон обмена сообщениями. Производители будут сервером в java, node и т.д. И клиентами будут - java настольные приложения, мобильные приложения (android/ios), браузер (JavaScript).

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

Случай использования. Сервер будет публиковать уведомления/сообщения по различным темам, и все клиенты (java/js/ios), подписавшиеся на набор тем, получат эти сообщения в режиме реального времени.

Я следил за тремя подходами к решению этих проблем 1 > socketIo/socketcluster 2 > исследовал протокол mqtt с mosquitto/rabbitmq в качестве брокера. 3 > изученный кафка

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

Первый подход прост и работает, но webSocket не является масштабируемым решением.

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

В-третьих, я изучил kafka, который известен тем, что я тестировал в Java, используя java api kafka высокого уровня, который можно использовать для подписки на тему kafka, и любое сообщение, опубликованное в этом разделе, доставляется клиенту в режиме реального времени.

Итак, мой вопрос заключается в том, насколько хорошо использовать клиентов kafka для оповещений в режиме реального времени, где все приложения для Java-приложений (может быть, миллион) будут включать этот клиентский SDK kafka java и будут подписаны на определенные темы, здесь я рассматривая каждого клиента как группу потребителей.

Также одна из основных проблем заключается в том, что этот клиент kafka имеет большой размер из-за его зависимостей scala, поэтому использование этого клиента в android не будет хорошим вариантом, и я не думаю, что он будет работать.

mqtt выделяется здесь, поскольку у него есть официальные клиенты phao для android, java, ios и т.д.

Кроме того, я не видел примеров в Интернете с использованием kafka для pub/sub messaging с миллионами потребителей, в основном люди используют его для передачи данных, например: обработка в режиме реального времени, загрузка данных в HDFS, механизм аналитики и т.д., обработка потока,

Основной вопрос заключается в том, как использовать протокол mqtt (который хорошо работает с android/ios/web/iot) с kafka в качестве брокера сообщений (который имеет высокую скорость публикации/подписки) и придумать масштабируемое решение этой проблемы.

Мой пример использования так или иначе похож на uber, где есть миллионы устройств android/ios (клиенты), и мы можем реально видеть движение в реальном времени всех автомобилей в нашем местоположении на карте, есть ли у кого-нибудь представление о том, что архитектура за этим отслеживанием автомобилей в режиме реального времени.

4b9b3361

Ответ 1

В этой статье описывается создание чатовой системы реального времени с использованием Kafka и node.js. Они также ссылаются на git repo, содержащий их пример. Вот что важно отметить из статьи:

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

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