Comments 15
Насчет гонцов и генералов, насколько я сведущ, очереди на основе AMQP (напр. Кролик) очень даже могут работать так, что если гонец успешно отправлен то рано или поздно он доедет и будет радушно принят. Но, в Кафке, вроде бы, все по другому ведь.
Но ведь он может доехать и после восьми утра
Это, конечно, да. Для такого случая уже надо какой-то собственный кастомный TTL в сообщении предусматривать. Т.е. если TTL истек, то отправитель считает что сообщение пропало, а получатель тогда его (когда получит), то игнорирует.
если гонец успешно отправлен то рано или поздно он доедет и будет радушно принят
Это если ваш гонец доедет до брокера, и его по дороге не скушают страшные волки (потери пакетов) или не окажется что мост разрушен и не проехать (сетевая недоступность брокера). Тогда гонец либо вернется обратно (с ошибкой сети) или и вовсе пропадёт без вести.
Передать сообщение в брокер - это считай сделать такой же REST-запрос, со всеми его возможными проблемами.
Вот если сообщение уже передали в брокер, то да, дальше всё гораздо лучше, получатель его прочитает рано или поздно, если не продолбается.
Ну так брокер нам (отправителю) ответит "ОК" только если он уже принял сообщение и положил его в своё (персистентное) хранилище для дальнейшей рассылки. В свою очередь подписчик (при нужной настройке очереди) убирает сообщение из очереди только явно, когда он его уже успешно обработал. Если он по дороге упал, то когда поднимется, то снова получит это сообщение.
Если в вашей метафоре "гонец отправлен" это "брокер принял сообщение и ответил ок", то да, верно. Но это ещё не обязательно случится.
И может ещё быть например, что брокер не ответил ок, но сообщение принял.
И может ещё быть например, что брокер не ответил ок, но сообщение принял.
Нет, такого как раз быть не может. Взаимодействие с самим брокером оно еще синхронное (в отличие от доставки) и если он ответил ОК, то он его принял. Другое дело, что если сообщение не "persistent", то он уже после этого может его потерять до того как отправит его получателю. Я не знаю как в Кафке - я раньше только кроликов разводил :)
И наверное ещё одна сторона кафки, которая может быть полезной - сообщения хранятся в брокере даже после прочтения.
Например, если попортили данные в БД, например стерли случайно таблицу, то можно восстановить БД сервиса из бэкапа, а потом накатить заново все сообщения с того времени по текущее время, даже те, которые уже были тогда прочитаны.
Если бы это был REST, то пришлось бы просить клиентов повторно отсылать запросы.
И ещё несколько архитектурных приёмов становятся доступны из-за того, что сообщения хранятся на брокере.
У Kafka много настроек, которые нужно дергать. С ними необходимо ознакомиться. А еще лучше - прочитать пару книжек, потому что условный “Hello world” можно сваять за час.
Что именно посоветуете? Порекомендуйте, пожалуйста.
Спасибо за интересную статью!
у нас огромный гигабайтные JSON-ы сжимаются при помощи колоночного формата
А можно по-подробнее насчет сжатия?
Kafka для самых маленьких разработчиков, аналитиков и тестировщиков