Я зовсім не розумію де я дав оцінку клієнту і його якості. Якщо в реальності ж описав проблему і сказав що треба правильно тюнити клієнт бо це є ще одним потенційним місцем зламати ордерінг.
Так а де issue про «якщо 1 месседж не опрацювався то в обробку може потрапити наступний»?
Ти ж своїм кодом контролюєш чи пропускати меседж чи падати, чи ретраяти, чи комітити офсет чи ні. Клієнт кафки тут немає значення.
але це вже треба вивчати і тюнити клієнт яким користуєтесь для обробки повідомлень.
ніхто ж не звинувачує клієнт, просто на цьому дуже легко спіткнутись, це треба конфіжити. Лінк на issue вище.
AWS FIFO SQS поддерживает до 300RPS на шард без батчинга(с батчингом в 10 раз больше). Просто SQS без FIFO без гарантий ’exactly-once delivery’ ЕМНИП еще раз 100 больше. Из коробки с почти конфигурированием за полчаса. Стоит копейки.
Я награв 30 годин і не згоден максимально) Ось простий приклад — все, чим спромоглися наповнити паркур, це мотузка для розкачування і вентилятори, які можуть здути.
Якщо ваш консьюмер скіпає дані, то це проблема вашого консьюмера, а не Кафки.
Є багато кейсів де треба вміти скіпати дані, так само як і багато кейсів де скипати ні в якому разі не можливо.
Коменчу давній пост — недавно стикалася з 2-ма проблемами самописного DI на чистому JavaScript:
1) В юніт-тестах класу передавалися всі потрібні залежності, а в реальному коді одна з залежностей не передавалася.
DOU DevOps meetup19 вересня (Київ)
Іван Ткаченко
Vadym Motsukh
Bohdan Vorona
Alexandr Gavriluk
Коментарі