Comments 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
Bitrix и Kafka: настраиваем интеграцию с брокером очередей