Комментарии 10
гарантия доставки - хотя бы один раз (at-least-once), используется БД Redis для этого
Redis имеет pub/sub. Понимаю, что у вас функций побольше. Но почему не Tarantul? Если правильно понял, то у тарантула есть все, что вы описываете.
А чем "БД Редис" не сервер?
Ее опциональной сделаю попозже.
Но без нее возникнут накладные расходы для обеспечения гарантии доставки: надо будет подверждения обратно слать после обработки сообщения (пусть не каждого, но всеравно), на той стороне нужен код, который это будет все слушать и тд
Скорее всего будет так: если без БД, то и без гарантии.
Redis тоже не дает особо гарантии. Он может быть in memory only, илм записью на диск, но все равно иметь возможности потери данных.
поток отправки при получении уведомления не сразу пишет сообщения в сокет, а немного ждет (по умолч 1мс, зашитый параметр компиляции)
Я не знаю, что за бенчмарки показывают такие результаты для ZeroMQ, но у меня вот прямо сейчас рабочий режим RabbitMQ — примерно 60К сообщений в секунду. Там есть свои заморочки с чтением, но сам брокер — даже не особо нагружает ядро.
В итоге в среднем имеем 10мс общего времени.
10к/10мс отсюда предположим линейно, что будет 1Млн сооб/сек
Ну дык у вас же не млн сообщений в сек. Или я не понял претензии или вопроса.
На бенчмарк я там ссылку дал, все там понятно написано, 50 строчек кода и Makefile тут же рядом.
Возможно у вас сервер мощный с кучей ядер и прочее (если вы считаете, что это очень мало), я тестил на своем рабочем ПК (core 11700).
а немного ждет (по умолч 1мс
Про это напишу еще.
Здесь упор сделан на bw (пропуск-ю способность), без задержки этой можно обойтись, обнулить при сборке, если нужно в первую очередь быстродействие.
Без нее часто будет выходить из потока отправки данных чуть раньше времени, чем новая порция сообщений для отправки придет. Все измерено было, с задержкой этой и без, то есть ее не просто так добавил.
Брокер сообщений на Rust