​​И первый публичный анонс нашего pub/sub-сервера. Сервер - PubSubRT, протокол - PSRT (IESG approved, port 2873)

В чем особенности сервера:

1) Минимально простая конфигурация. На производительность влияет только один параметр - data queue. Чем он меньше - тем меньше latency, но клиент может дольше ждать перед отправкой сообщения

2) Работает максимально быстро, даже с большими пейлоадами. И да, latency на хорошей сети редко поднимается выше 0,5 ms (для мелких пейлоадов - в пределах 30-40 микросекунд)

3) Это не "черный ящик". максимальный мониторинг всего, что происходит внутри

4) Жесткое слежение за latency, warnings в логи, как только превышается допустимый параметр

5) Никаких "таблиц подписки" - только b-trees. Клиенты могут задать миллионы подписок на разные топики, но если сообщения не ходят сразу в миллион клиентов бродкастом - сервер этого не замечает.

Latency между паблишером и конкретным подписчиком мы считаем, как время с момента получения от паблишера первого байта OP_PUBLISH и до ухода последнего байта в дата-сокет подписчика

В чем особенности протокола. Основная особенность одна - мы использовали два сокета (на один порт) и отказались от карусели OP-ACK. Аргумент против один: это усложняет написание надежного клиента, впрочем клиенты на Rust и Python уже вполне надежные. Теперь аргументы в пользу:

- В Pub/Sub пуши от сервера приходят только когда вы получаете сообщение. поэтому пусть себе и ходят по выделенному сокету данных

- По сокету управления все операции - атомарные. Карусель OP-ACK на клиенте тоже не нужна, что намного облегчает логику

- Благодаря двум сокетам, сервер может посылать ACK на операции контроля прямо в то время, пока клиент по второму сокету скачивает большой пейлоад

- Внезапно, но есть куча клиентов, которые просто отправляют данные и ни на что не подписываются. В PSRT данные на сервер можно пушить хоть UDP-фреймами, с ACK или без

- Нет retains. На высоконагруженных Pub/Sub от них всё равно рано или поздно отказываются, потому что это обычно операции с диском

- Очень жесткий контроль таймаутов. Дохлый клиент будет с сервера немедленно выброшен. Дохлый сервер будет немедленно переподключен клиентом

- Максимально простой запуск TLS

- Репликация и HA из коробки. В сервере мы ее пока не открывали, но в будущем думаю да. Протокол репликации открыт

- Логическая совместимость с MQTT - те же топики, те же маски

Все это уже работает в продакшне у клиентов. Реальное ускорение с пейлдоадами >10kb на медленных каналах (нестабильный 1Mbit) - в 5-10 раз быстрее, чем MQTT. Наша EVA ICS уже получила поддержку PSRT в дополнение к MQTT, релиз выйдет примерно через месяц.

https://github.com/alttch/psrt