Comments 16
Я почему-то думал, что под "строго однократной доставкой сообщения" понимается решение на стороне отправителя, а по факту это прослойка на получателе с заведомо надежным каналом до API. Отправитель-то в итоге все равно будет перепосылать сообщения, если ответ от получателя не дошел.
Вот это наверное уже читали: https://news.ycombinator.com/item?id=14670801?
Больше выглядит что проблема в самом протоколе, т.к. "доставить хотя бы один раз" и "проверить совпадение данных" — это так работают множество успешных проприетарных протоколов без необходимости городить аппарат согласования.
Во-вторых, все эти допущения о размере по сути "кеша" сообщений вызывают у меня тихий ужас, когда такой дизайн связан в финансами. При переполнении всё равно не достигнута заявленная цель "доставить один раз".
Если вопрос стоит о снижении нагрузки на ядро для избежания обработки дубликатов. Ну, сделайте промежуточный узел с кешем. Если предыдущий запрос есть в кеше в таком же виде и имеется результат, отдайте ответ без обработки в ядре. Если нет, пересылайте в ядро — это не то же, что "доставить ровно один раз".
Возможно авторы именно это и сделали, я упустил момент где клиент получает ответ на повтор.
Использованный термин "дедупликация" как-то из оперы об эффективном хранении данных, а не обмене сообщениями. Тут скорей нужно придумать "deretransmission".
Deretransmission опять упрется в неполучение ACK отправителем. Разве что делать полноценные keep-alive соединения с двунаправленным трафиком, но тогда теряется сам смысл попытки уменьшить трафик путем уменьшения количества переданных сообщений. А с дедупликацией принятого должен справляться сам TCP.
Или используя подобное решение, или делать ack после каждого сообщения (прощай пропускная способность).
Пожалуйста, укажите суточное кол-во сообщений, кол-во сообщений в пике за минуту.
P.S. еще раз перечитайте литературу по теории массового обслуживания.
Доставка миллиардов сообщений строго один раз