Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka. Глава 2. ActiveMQ

[Throwable]

Как только брокер удостоверится, что сообщение сохранено, он отправит клиенту ответ-подтверждение (4). После чего, поток клиента, первоначально вызвавший операцию send (), может продолжить свою работу.

Во всех подобного рода туториалах реальная проблема замаскирована подобным образом. Очень детально рассмотрено взаимодействие с хардом и дисками, и совершенно не рассмотрен более частый случай сбоя сети: подтверждение может просто не прийти к клиенту, хотя со стороны брокера запись сообщения в хранилище произведена, а подтверждение отправлено. Здесь можно сослаться на сложные архитектурные решения и протоколы ввиде JTA, two-phase commit, XA, etc, но если хорошо подумать, то это только маскирует реальное положение вещей: при помощи асинхронного сетевого TCP/IP невозможно обеспечить полную гарантию "exactly once".

Существует ряд способов получения большей производительности от инфраструктуры брокера

• Откажитесь от гарантии (exactly once), тем более, что она не работает. Вместо этого вставьте в консьюмер простую проверку на дубликаты.
• По возможности не пересылайте критические данные сообщениями. Вместо этого синхронизируйте реальные данные между системами при помощи сторонних API. Сообщение — это лишь индикатор, что что-то изменилось (возможно), и что данные устарели.
• В сценариях, подобному выше, персистенция не нужна, если состояние полностью синхронизируется при старте.