Comments 1
Как только брокер удостоверится, что сообщение сохранено, он отправит клиенту ответ-подтверждение (4). После чего, поток клиента, первоначально вызвавший операцию send (), может продолжить свою работу.
Во всех подобного рода туториалах реальная проблема замаскирована подобным образом. Очень детально рассмотрено взаимодействие с хардом и дисками, и совершенно не рассмотрен более частый случай сбоя сети: подтверждение может просто не прийти к клиенту, хотя со стороны брокера запись сообщения в хранилище произведена, а подтверждение отправлено. Здесь можно сослаться на сложные архитектурные решения и протоколы ввиде JTA, two-phase commit, XA, etc, но если хорошо подумать, то это только маскирует реальное положение вещей: при помощи асинхронного сетевого TCP/IP невозможно обеспечить полную гарантию "exactly once".
Существует ряд способов получения большей производительности от инфраструктуры брокера
- Откажитесь от гарантии (exactly once), тем более, что она не работает. Вместо этого вставьте в консьюмер простую проверку на дубликаты.
- По возможности не пересылайте критические данные сообщениями. Вместо этого синхронизируйте реальные данные между системами при помощи сторонних API. Сообщение — это лишь индикатор, что что-то изменилось (возможно), и что данные устарели.
- В сценариях, подобному выше, персистенция не нужна, если состояние полностью синхронизируется при старте.
+2
Sign up to leave a comment.
Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka. Глава 2. ActiveMQ