1. Чтобы горизонтально масштабировать, плюс так сложилось, что мне когда есть очередь проще понимать, что происходит в системе в целом чем когда рест апи. Может я какой-то испорченый :)
2. Читал гайд по практикам к RMQ там было сказано, что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?
3. Kafka мне говорили сложно в плане менеджмента и поддержки. RMQ/NATS/Google Pub/Sub - примерно такие я слышал рекомендации.
Если у тебя один продьюсер, то ничего масштабировать не получится, он будет бутылочным горлышком
Если у тебя несколько продьюсеров, то гарантировать отсутствие дублей на стороне продьюсера будет очень сложно
Самый простой вариант — добавить гарантию того, что одно и то же сообщение попадёт в один и тот же консьюмер (например, шардирование) и, как сказал
@maxlapshin , читать идемпотентно, запоминая прочитанные сообщения (не обязательно все, можно очищать старые запо
И вообще, зачем тут кролик. Сделать пулл модель — консьюмеры делают
REST
запрос в продьюсер когда они ничего не обрабатывают (или обработка вот-вот кончится),
REST
это совсем не дорого, особенно учитывая что практически любой
http
-клиент в наше время умеет держать соединение и инициировать его с
tcp fast open