mayton2019

Если у тебя будет 100 нод-получателей то полюбому хотя-бы одна из них будет недоступна в момент отправки.
Такова природа вещей. И не стоит требовать от сетей перфекционизма. Сети работают как погода. Как дождь
или снег. Надо это учитывать.

Поэтому брокер сообщений на базе Kafka или Apache Pulsar или Rabbit будет вполне себе реальным решением.

Ты пишешь про p2p. Но какой ценой этот p2p ты собираешся поддержать на продюсере? Ты создашь 100 сокетов
и 100 буферов отправки сообщений?

Потому что другого выхода у тебя на самом деле нет. Или у тебя просто не пройдет транзакция я гарантирую
это.

Очереди могут обеспечить exactly once. По крайней мере в настройках у многих есть такой параметр.

Дедубликация - это слишком жесткое требование. Оно требует хранения ключей в неких индексах
которые должны быть консистентны. Это - ближе к базам данных. А очереди обычно используют
достаточно простые и плоские структуры (файлы) для хранения месседжей.

Если в стеке технологий у вас стоит Redis - то можно его использовать для очереди
https://redis.com/redis-best-practices/communicati...

В Kafka log файлы обычно большого размера. И поиск в них - последовательный. В силу специфики. Месседжи - имеют произвольный размер. А индексный файл - маленький. И записи - по 64 бита. Можно быстро найти нужную. Тем более там есть ордеринг.

Вопрос - странный. Ну если вам нужно быстро - то отправляйте батчем. Собственно - это такой общий паттерн который можно рекомендовать всегда. Как - советовать носить шерстяные штаны зимой.

Почему медленно когда по 1 сообщению? Идей много. Как вариант - виновата сетевая латентность и некие усиленные проверки транзакций или квитирований с вашей стороны. Вот по этому пункту нужно смотреть конфигурации и пинговать и трассировать ваши сети.