Как работать с онлайн-пользователями, подключенными к различным серверам в централизованном приложении обмена сообщениями?

Question

Я создаю централизованную программу обмена сообщениями на Python, похожую на старый MSN Messenger или WhatsApp.Допустим, теперь мой сервер может обрабатывать около 50 000 онлайн-пользователей, и он работает следующим образом:

user1 хочет отправить сообщение пользователю 2, поэтому user1 отправляет сообщение серверу, сервер ведет огромный списокв памяти, которая отображает пользователей и их IP-адреса, поэтому, если пользователь2 подключен к сети, сервер пересылает сообщение пользователю2, если пользователь2 не подключен, сообщение сохраняется на сервере до тех пор, пока пользователь2 снова не подключится и не запросит новые сообщения.

Теперь моя проблема: допустим, программа растет с точки зрения количества пользователей, и теперь мне приходится обрабатывать 200 тыс. Пользователей, поэтому мне нужно 4 сервера.Каков был бы самый простой способ обработать процесс «нахождения», к какому серверу подключен пользователь2, чтобы переслать ему сообщение?Может быть, «Сервер маршрутизатора», который отображает всех пользователей в сети на всех серверах, так что сервер, к которому подключен пользователь 1, пересылает сообщение на сервер X, где подключен пользователь 2?и если это лучший способ, что я могу сделать, когда пользователь находится в автономном режиме, возвращается в онлайн и «запрашивает» новое сообщение на случайном сервере?как я могу получить все его новые сообщения?

Может быть, другим способом может быть то, что сервер, когда подключен пользователь 1, передает запрос на остальные серверы, спрашивая, подключен ли пользователь 2 к ним?

Заранее спасибо, ребята

Answer 1

Я бы разделил проблемы (и соответствующие технологии / протоколы):

1. протокол обмена сообщениями с пользователями (непоследовательная отправка, последовательная репликация журнала входящих сообщений)
2. распределено по- сохранность регистра получателя
3. соединение # 1 и # 3

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

Для # 1, # 3 вы должны иметь возможность быстро взломать что-нибудь вместе с asyncio, zeromq и т. д.

Для # 2 Iпопытался бы найти какое-то существующее промежуточное ПО, способное масштабироваться как кластер (Kafka, Ignite и т. д.).

Прелесть этого подхода в том, что в первом прототипе вы можете макетировать # 2 с помощьюединая централизованная БД, так что все это будет работать практически мгновенно, в то время как вы узнаете, как настроить распределенное постоянство, настроить его, контролировать и т. д.

Отличностатья инженера LinkedIn, которая должна помочь вам правильно разобраться в проблеме - Журнал: что должен знать каждый разработчик программного обеспечения об объединяющей абстракции данных в реальном времени .