Comments 5
При возникновении какой-либо ошибки в процессе работы сервиса полученное сообщение могло быть помещено в dead-letter-queue (DLQ) для дальнейшего ручного разбора
…
MongoTimeoutException при запросе в MongoDb
Можно конкретизировать пример? Допустим, при нормальной обработке сообщения нужно работать с MongoDb, и оттуда пришел MongoTimeoutException. Какой смысл писать сообщение в DLQ, не проще/правильнее повторить обработку?
Да, конечно. Сразу хочу отметить, что в тексте статьи я сначала описал общий случай с записью в DLQ, а затем частный с применением стратегии повторных вызовов.
Если мы могли понять, что ошибка имеет временный характер, то мы начинали применять стратегию повторных вызовов. В этом случае сообщение попадало в DLQ только если наступил конец стратегии, не раньше.
Во всех остальных случаях сообщение сразу попадало в DLQ.
Если мы могли понять, что ошибка имеет временный характер, то мы начинали применять стратегию повторных вызовов. В этом случае сообщение попадало в DLQ только если наступил конец стратегии, не раньше.
Во всех остальных случаях сообщение сразу попадало в DLQ.
Тем кто не использует специфические решения и кому достаточно стандартных технологий (Kafka Connect) может быть интересна статья "Kafka Connect Deep Dive – Error Handling and Dead Letter Queues".
- Если остановить listener container не происходит ребалансировка consumer group?
- Насколько долго выполняется обработка сообщения? Если делать комит offset после обработки сообщения и добавить сюда spring retry то можно выскочить за timeout обработки сообщения.
- И еще всегда хотел спросить — какое количество партишенов для топика считается нормальным?
Я понимаю что все зависит от размера кластера, но может есть какие-то рекомендации.
Спасибо за вопросы. Отвечу на них по порядку
- При остановке и поднятии listener container происходит остановка и поднятие consumer-a, а это приведет к ребалансировке. Хотя, при временной недоступности внешней системы скорее всего будут остановлены все consumer-ы в затронутой consumer group.
- Время обработки сообщения отличается от сервиса к сервису. На одном из наших контуров для приложений, которые ходят в несколько внешних источников за данными, оно не превышает 50 мс. Как я и писал, spring-retry мы не стали серьезно рассматривать. Он хранит сообщения в памяти, блокирует поток исполнения для выполнения стратегии и с ним у нас по прежнему отсутсвует DLQ. Кроме того, действительно, есть вероятность превысить max.poll.interval.ms интервал, что приведет к нежелательной ребалансировке consumer group.
- Я затрудняюсь ответить на этот вопрос. Мои наблюдения показывают, что количество партиций должно соответствовать количеству consumer-ов для эффективной утилизации. Если consumer-ов будет больше, чем партиций, то они будут простаивать. Если партиций будет больше, то какой-либо consumer подключится и будет читать из нескольких партиций сразу, что может негативно отразиться на производительности.
Sign up to leave a comment.
Повторная обработка событий, полученных из Kafka