Срок хранения сообщений в топиках у нас обычно не менее 7 дней, но можно и больше, главное чтобы дискового хранилища на серверах было достаточно. Это время для устранения проблем с получателями. Состояние всех получателей всегда мониторится Burrow. Если у какого-то получателя начал расти лаг, то на это срабатывает датчик и далее принимаются меры.
Также при ошибках обработки сообщений получатели отправляют сообщения в DLQ топики. DLQ топики мониторятся для разбора проблем. Можно, например, устранить проблему в коде и сообщения из DLQ перебросить обратно. Другая ситуация - получатель забрал сообщение и не смог выполнить комит своего офсета, связь пропала. Тогда после восстановления связи, сообщение будет обработано еще раз. Идемпотентность в таком случае зависит от бизнес логики, какие-то сообщения у нас перезаписываются, а какие-то пропускаются, т.к. уже были обработаны.
Получатели не только читают, но и подтверждают получение, что приводит к удалению записей. Сейчас, например, у нас там есть кэш, чтобы реже обращаться к БД за чтением. Но в любом случае использование OLTP БД для очередей это антипаттерн, который приносит много проблем.
В кафке хранится текущее смещение получателя в топике, чтобы продолжать чтение. Также настраивается максимальный срок хранения сообщений или предельный размер топиков. Т.е. заранее рассчитывается необходимый размер дисков исходя из желаемого срока хранения, количества сообщений и их размера.
На момент выбора уже был положительный опыт использования Apache Kafka в других продуктах компании. Т.е. не пришлось тратить время на изучение RabbitMQ с нуля.
Kafka имеет возможность обеспечения нужной нам exactly-once гарантии доставки.
Pull больше подходит в сравнении с push, т.к. получатели это кассы, на которых железо не всегда достаточное мощное. Предпочтительно, чтобы они сами управляли интенсивностью получения данных, а не брокер.
Также в кафке используем Stream API для построения онлайн агрегатов.
Несколько раз пригодилась возможность перечитать сообщения заново.
Срок хранения сообщений в топиках у нас обычно не менее 7 дней, но можно и больше, главное чтобы дискового хранилища на серверах было достаточно. Это время для устранения проблем с получателями. Состояние всех получателей всегда мониторится Burrow. Если у какого-то получателя начал расти лаг, то на это срабатывает датчик и далее принимаются меры.
Также при ошибках обработки сообщений получатели отправляют сообщения в DLQ топики. DLQ топики мониторятся для разбора проблем. Можно, например, устранить проблему в коде и сообщения из DLQ перебросить обратно.
Другая ситуация - получатель забрал сообщение и не смог выполнить комит своего офсета, связь пропала. Тогда после восстановления связи, сообщение будет обработано еще раз.
Идемпотентность в таком случае зависит от бизнес логики, какие-то сообщения у нас перезаписываются, а какие-то пропускаются, т.к. уже были обработаны.
Получатели не только читают, но и подтверждают получение, что приводит к удалению записей.
Сейчас, например, у нас там есть кэш, чтобы реже обращаться к БД за чтением. Но в любом случае использование OLTP БД для очередей это антипаттерн, который приносит много проблем.
В кафке хранится текущее смещение получателя в топике, чтобы продолжать чтение. Также настраивается максимальный срок хранения сообщений или предельный размер топиков. Т.е. заранее рассчитывается необходимый размер дисков исходя из желаемого срока хранения, количества сообщений и их размера.
Причин было много, вот одни из них:
На момент выбора уже был положительный опыт использования Apache Kafka в других продуктах компании. Т.е. не пришлось тратить время на изучение RabbitMQ с нуля.
Kafka имеет возможность обеспечения нужной нам exactly-once гарантии доставки.
Pull больше подходит в сравнении с push, т.к. получатели это кассы, на которых железо не всегда достаточное мощное. Предпочтительно, чтобы они сами управляли интенсивностью получения данных, а не брокер.
Также в кафке используем Stream API для построения онлайн агрегатов.
Несколько раз пригодилась возможность перечитать сообщения заново.