- Как это работает сейчас
На данный момент мы имеем клиент-серверную архитектуру, построенную путем создания клиента, чат-комнаты, сервера как отдельных подсистем с возможностью запуска на разных машинах и возможностью асинхронного обмена сообщениями по TCP/IP протоколу. Сервер, клиент, комната стартуют на машине как акторы с использованием неблокирующих mailbox для асинхронного обмена сообщениями. Клиент может подписываться и отправлять сообщение размером 254 байта PublishToChatRoom в комнаты, указанные в списке доступных для клиента. При подписании от сервера к комнате поступает сообщение newClientInRoom и комната отправляет историю сообщений клиенту, которую хранит в виде кольцевой очереди в памяти (in-memory), отображая клиенту последние 128 сообщений.
- Что изменится
Для горизонтального масштабирования, увеличения пропускной способности и отказоустойчивости благодаря использованию модели акторов есть возможность нарастить серверы добавив обмен между ними по событию через EventBus акторов или MQ различных брокеров, например, Redis c различными persistent сценариями или (Kafka, Amazon SQS и т.д). Для доступности чат-комнат также стоит учесть вариант обмена сообщениями в случае отказа или недоступности комнаты. При хранении истории БД на 1 год следует учесть, что при 128x254x365 = 11866880 байт необходимо для хранения истории на один год для одной комнаты, в зависимости от числа комнат происходит линейный рост выделения размера базы данных для архитектуры к примеру для 10000000 комнат необходимо ≈ 140 ТБ. Для выбора БД стоит принять во внимание следующие характеристики:
- Размер базы данных
- Пропускная способность
- Цена базы данных
- Платформа
- Защита данных
- Требования к железу
- Сложность настройки, установки, администрирования, поддержка
- Перспективы развития