Ультимативный подход для realtime систем: Чаты, игры, IoT и акторы

Как я чаще всего структурировал подобные системы:

. Сокет – сервис, который держит WS / TCP / UDP / MQTT соединения, он существует отдельно, чтобы когда мы редеплоим или масштабируем сервисы с бизнес-логикой соеднинения не отваливались.

. Ресивер – сервис обработки сообщений с основной бизнес-логикой.

. Командер – опционально, но в IoT чаще всего нужен сервис, который мапит ваши команды в команды, которые будет понимать устройство и отправляет их.

Сообщения приходят в Сокет, идут в Ресивер, он отправляет команды ответа Камендеру и тот отправляет сообщения через Сокет (очень CQRS-ный подход с раздлением потока чтения и записи)

Какие полезные трюки важно помнить:

. Сервисы должны общаться асинхронно (не ждать ответа) иначе вы рано или поздно будете попадать в dead lock всей системы.

. Соответственно, все сообщения должны представлять собой "события" (event) – структуру описывающие произошедший факт с данными об этом факте ("ПользовательСоздалСообщение", "СообщениеУспешноОбработано", "СообщениеУспешноОтправлено", etc.)

. Сокет должен содержать минимум логики, чтобы его не приходилось часто редеплоить ИЛИ если вам больше важно скорость, тогда объединяем Сокет, Ресивер и Командер

. Все сообщения стоит хранить персистентно (Kafka или БД)

. В Realtime системах максимально важны 2 фактора: скорость и линейный рост нагрузки при увеличение числа сообщений.

Хочу обратить внимание именно на последний пункт: чаще всего, самым узким горшлышком вашей системы будет не язык программирования, не транспорт и не сеть, а обращения в БД.

Во-первых, каждое обращение – это время, во-вторых, запросы к БД сложно батчить, потому что каждое сообщение процесситься независимо друг от друга, в-третьих, если у вас не master-master база у вас будет ограниченное число коннектов.

Все это приводит к тому, что увеличение числа сообщений в секунду экспоненциально увеличивает нагрузку.

Чтобы сделать скорость обработки сообщений константной, а рост нагрузки линейным лучшим вариантом будет доставать нужные данные в момент старта сервиса (или прихода первого сообщения), класть их в память (или в кэш типа Redis), с каждым сообщением проводить измения данных прямо в памяти и время от времени синхронизировать данные с основной базой

Задача не из легких, но именно тут нам на помощь приходит паттерн "Акторы"

Акторы очень хорошо описывают то, как максимально удобно и понятно структурировать логику подобного рода.

Сообщение получилось итак слишком большим, поэтому продолжение в следующей части, а пока посмотрите видос про акторы, который я еле откопал:

https://www.youtube.com/watch?v=Fw-CXSG8KZE

а почему именно при старте сервиса?

не проще проекции вязать к сокету пользователя, с инфой для конкретного пользователя?

полное зеркало базы дорого по памяти.

*это если про ram, если в redis то можно и всю базу...

Дополнил, что можно их класть в память при приходе первого сообщения)

Про память: несомненно нужно посчитать средний / максимальный размер нужных для выгрузки данных и от этого принимать решение где именно будет хранится (+ кэш более надежный, в случае падения приложения)

В следующих статьях я буду рассказывать про схему построения из 3-х слоев: мемори, кэш и БД – и стратегии их использования в зависимости от условий

Ну и расскажу про один неожиданно крутой кэш именно для Акторной модели

Почти все что было сказано решает Centrifugo.

Когда-то давно писали с ребятами проект на Django и как раз использовали Centrifugo, но именно как Сокет сервис (держала WS), на который можно было напрямую подписаться

Она умеет ещё что-то?

Клиенты могут делать через нее RPC вызовы напрямую. Сообщения может хранить в Redis, Dragonfly. API для вытаскивания истории сообщений при лавинообразном реконнекте после падения это очень полезно.
Метрики отдает.
На подходе HTTP 3.

Кайф, получается сокет + транспорт + хранилище, удобно

А у нее есть кластеризация? Master master? Нашел

И да, очень важный вопрос: какие у нее недостатки?

У dapr про акторы хорошо написано и на сайте msdn есть раздел