Иван Шумов

Единорогов не существует. В принципе даже если взять 2 пункта из 4, любые - таких брокеров гарантированно быть не может. Как минимум по тому что 0 и 1 - несовместимые с жизнью требования, а 4 не является вообще зоной ответственности очереди. Ну и в догонку - пункт 2 где-то может и есть, но есть миллион причин так не делать

Выбираем на вкус и цвет брокера тут

1. Что такое приличная нагрузка? (в цифрах)
2. Если мы говорим про высокие нагрузки и последовательные операции то у меня для вас очень плохие новости (так не бывает, не говоря уже про то что очереди за это не отвечают)
3. Задача один раз - CQRS паттерн + Correlation token ( и даже при этом 100% не достигнуть)
4. Если мы говорим про высокие нагрузки то стоит забыть про "поставил и забыл". Больно будет обязательно
5. Что делает RabbitMQ в тегах?

- Тюнить конфиг кролика
- Тюнить конфиг сервера
- Мониторить логи
- мониторить параметры сервера (диск, проц, память, одновременное число сообщений)
Перестать пользоваться принципом fire and forget и контролировать в скрипте факт успешной доставки сообщения в очередь с exponential retry

Да никак. В очереди должны быть только сообщения, требующие обработки. Не для того вы из используете. Если так удобнее надо вам это делать то добавьте хранилище с блокировками и если оно там то сообщение должно быть проигнорировано, а метка из блокировки стерта

Смотрите - есть 2 основные механики - push-based и pull-based. pub/sub это просто один из принципов очередей де факто.

то что вы хотите реализовать это отличие exchange и queue в RabbitMQ. ZeroMQ вообще никому не посоветую, да и Redis не очень про очереди - просто немного умеют в них