Высокий уровень дизайна для мессенджера, как приложение Whats?
Мне нужно спроектировать подобные вещи, такие как приложение Whats или любой мессенджер-подобный модуль.
Высокий уровень потока
Client > Load Balancer > Web servers(assume 10 clustered server for now) > Rest based controller > Service > DAO > DB
Вызов:-
скажем, друг 1 и друг 2 онлайн. Друг 1 установил веб-соединение HTTP с веб-сервером 1, а Друг 2 установил веб-соединение HTTP с веб-сервером 2. Друг 1 отправил сообщение другу 2.
Теперь, как только сообщение приходит на веб-сервер 1, мне нужно передать сообщение на веб-сервер 2, чтобы его можно было отправить другу 2 через уже установленное веб-соединение.
У меня есть пара связанных вопросов здесь: -
- Я могу использовать распределенные очереди для распространения сообщения с одного сервера на другой. Как только сообщение поступает на один сервер, оно отправляет его в распределенную очередь (распределяет очередь из-за распределения нагрузки и высокой доступности) с содержимым сообщения, начиная с пользовательского идентификатора и заканчивая пользовательским идентификатором. Мой вопрос, как правильный сервер (в данном случае веб-сервер 2) будет уведомлен? потому что, если я использую очередь JMS, только один сервер будет уведомлен через слушателя. Если я использую тему, все серверы будут уведомлены. В этом случае все серверы могут отклонить сообщение, кроме одного сервера, на котором находится fromUserId. Есть ли лучший способ, когда очередь просто уведомляет нужный сервер на основе метаданных?
Также, если destinationUserId не в сети, мне нужно вернуть сообщение в очередь. Не уверен, как это может быть достигнуто? Я считаю, что нам нужно использовать какую-то другую реализацию очереди (возможно, очередь на основе Java в памяти) вместо очереди / темы JMS? Код сервера удалит сообщение из пользовательской очереди только после получения подтверждения от клиента.
Если какой-либо клиент находится в автономном режиме во время отправки сообщения, в этом случае, когда он выходит в сеть, он отправит запрос на извлечение. Сервер сделает запрос в распределенную очередь, распределенная очередь извлечет сообщение из правильной физической очереди. Мой вопрос, если распределенная очередь будет сохранять destinationUserId и сообщение как значение в метаданных?
БД против очереди: - Я полагаю, что при таком подходе нет необходимости хранить сообщение в БД, которое может быть дороже (сложность времени), чем очередь (очередь в памяти) в приложениях с высокой степенью реального времени, таких как мессенджер. Нам просто нужно хранить детали пользователя / группы в БД.
Обновление: - Я нашел связанную ссылку в кворе, где последняя точка, т.е. What protocol is used in Whatsapp app ?... Kah Seng Tay также подтверждает подход simialr с использованием очереди, но все же на мои вышеупомянутые вопросы об очереди еще предстоит ответить.