Kafka даёт максимальную производительность (из-за которой её и используют ) в режиме автокоммитов оффсетов или редких ручных коммитов. Автокоммит, кстати, сконфигуирован в Kafka по дефолту в true. Видел проекты, где разработчики вешают аннотацию коньсьмера кафка на метод и вроде как получают сообщения и все у них работает, но упускают из виду дефолтный автокоммит, что может привести к ситуации, когда коммит оффсетов произошёл, а данные не загрузились в целевую систему, вот и потеря сообщений, причём даже в логах не найдёте информацию о потерях. При редких ручных коммитах чтобы не было потерь у нас должны быть огромные пачки сообщений обрабатываться за раз, что чревато ошибками и необходимостью переотправки. Про дубли - например после ребалансировки консьюмеров не удастся закоммитить оффсеты в той же сессии, при попытке коммита будет exception. Поэтому надо хранить оффсеты обработанных сообщений где-то ещё, во внешнем хранилище, обычно я в zookeer храню. Это только малая часть проблем. Вывод такой - Kafka имеет очень много особенностей эксплуатации, и если у вас в команде нет эксперта по ней, то легко нарветесь на какой нибудь мало понятный баг. Под Jms я имел ввиду именно спецификацию. Здесь все гораздо проще - есть спецификация, есть транзакции в Jms, и даже новичек сможет писать гарантированно работающий код. Конечно, в каждом конкретном случае, в зависимости от требований отказоустойчивости, нагрузки обдуманно выбирается то или иное решение jms, kafka, кэш или что то ещё. Зависит от кругозора архитектора. Про rabbitmq - мы принципиально не пользуемся им, т.к. он плохо горизонтально масштабируется и высока вероятность split brain кластера под нагрузкой, после которого кластер разваливается и лечится только полной очисткой данных.

Stanislav Bashkyrtsev,

>>Необходимо уведомлять несколько приложений о событии, причем логика того, какие приложения нужно уведомлять, а какие нет (раутинг), может менятся.

>А для чего это делается?

Например, b2c и b2b ордера обрабатываются в разных приложениях, хотя и те и те обрабатываются одним customer information management приложением.
Потребовалось по дргугому обрабатывать ордера b2g клиентов.

Stanislav Bashkyrtsev,

>Добавляем кэширование на сервере в nginx'e эдак в одну минуту и вся нагрузка с сервера резко уйдет. Т.е. надо чтоб все долбящиеся клиенты кроме 1ого получали ответ из кеша.

Это помогает только в самых тривиальных случаях, когда всем нужен один и тот же объект.
А если это web портал, которому нужно получать нотификацию об обновлении для конкретного кастомера, у которого открыта сессия.

Stanislav Bashkyrtsev, При ручных коммитах производительность проседает, потому, что синхронный коммит оффсетов - блокирующая операция (асинхронный коммит не рассматриваем из-за отсутствия гарантий). Там путь такой обычно - оффсеты запросом клиента доставляются на один из узлов Кafka, потом реплицируются на другие узлы Кafka, в соответствии с настройками репликации, а потом уже синхронно ответ возвращается клиенту. И так каждый раз при ручном коммите.
Для продюсера Kafka ситуация другая, в памяти клиента организуется буфер, в который продюсеры с разных программных потоков складывают информацию, а потом отдельный поток отсылает всю накопленную пачку в Kafka.
Поэтому продюсеры работают быстро, а оффсеты коммитятся медленно.