Как стать автором
Обновить

Комментарии 6

гарантия, что сообщения будут прочитаны в порядке их попадания в хранилище;

достаточно спорно, в частности, если мы уже дошли до групп консумеров и партиций.

...

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

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

гарантия, что сообщения будут прочитаны в порядке их попадания в хранилище;

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

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

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

Не совсем так, горизонтальное масштабирование возможно и когда порядок сообщений важно не нарушить.

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

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

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

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

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

Это мой личный экспириенс )

Но практика показывает, что чем больше консьюмеров задействовано, чем
больше очередей создано и чем больше информации передается, тем чаще не
хватает производительности RabbitMQ

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

Разрабатываемое и поддерживаемое нами web-приложение является небольшим звеном большой IT инфраструктуры заказчика, в которую входят другие приложения, физические магазины, склады и тд. Поддержкой и развитием Apache Kafka в данном случае мы не занимались, поэтому я не могу сообщить объём данных, проходящий через брокера.

Я понимаю Ваш вопрос, насколько сильно нужно «разогнаться», чтобы не хватило кролика. Когда начинаются высоконагруженные BigData системы и сотни тысяч сообщений в секунду и горизонтально масштабировать RabbitMQ становится уже затратно. Думаю, что роль Kafka также будет правильно рассматривать, как часть ESB, когда Kafka дополняет её своими плюшками и отказоустойчивостью.

Видел материал, как искусственно сравнивали скорость работы на больших данных кафки и кролика:

https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.