Comments 10
Почему именно Apache Kafka? Чем RabbitMQ не устроил?
Причин было много, вот одни из них:
На момент выбора уже был положительный опыт использования Apache Kafka в других продуктах компании. Т.е. не пришлось тратить время на изучение RabbitMQ с нуля.
Kafka имеет возможность обеспечения нужной нам exactly-once гарантии доставки.
Pull больше подходит в сравнении с push, т.к. получатели это кассы, на которых железо не всегда достаточное мощное. Предпочтительно, чтобы они сами управляли интенсивностью получения данных, а не брокер.
Также в кафке используем Stream API для построения онлайн агрегатов.
Несколько раз пригодилась возможность перечитать сообщения заново.
По факту, вы приспособили kafka к классическому MQ брокеру (через envent сообщения). Решение не бесcпорное, но учетом простоты работы/эксплуатации kafka имеет свои преимущества.
Но как решается "очистка" топиков от уже не нужных (доставленных сообщений). Я не нашел этого в статье.
В кафке хранится текущее смещение получателя в топике, чтобы продолжать чтение. Также настраивается максимальный срок хранения сообщений или предельный размер топиков. Т.е. заранее рассчитывается необходимый размер дисков исходя из желаемого срока хранения, количества сообщений и их размера.
То что есть настройки log.retention.* это не ответ .
Мне интересно как быть с гарантированной доставкой, если по каким то причинам получатель не забрал сообщение, а по настройкам кафки оно "ушло" из лога кафки.
Или вы просто принимаете этот риск?
Срок хранения сообщений в топиках у нас обычно не менее 7 дней, но можно и больше, главное чтобы дискового хранилища на серверах было достаточно. Это время для устранения проблем с получателями. Состояние всех получателей всегда мониторится Burrow. Если у какого-то получателя начал расти лаг, то на это срабатывает датчик и далее принимаются меры.
Также при ошибках обработки сообщений получатели отправляют сообщения в DLQ топики. DLQ топики мониторятся для разбора проблем. Можно, например, устранить проблему в коде и сообщения из DLQ перебросить обратно.
Другая ситуация - получатель забрал сообщение и не смог выполнить комит своего офсета, связь пропала. Тогда после восстановления связи, сообщение будет обработано еще раз.
Идемпотентность в таком случае зависит от бизнес логики, какие-то сообщения у нас перезаписываются, а какие-то пропускаются, т.к. уже были обработаны.
Ещё одна статья про gzip :)
Вы рассматривали такой вариант: сделать несколько зеркал к основной БД, настроить кассы на чтение с этих зеркал и пускай они их нагружают запросами?
Apache Kafka для магазинов