Мне нужно разработать аналогичные вещи, такие как приложение 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 через уже установленное веб-соединение.
У меня есть пара связанных вопросов:-
- Я могу использовать распределенные очереди для передачи сообщения с одного сервера на другой. Как только сообщение поступает на один сервер, оно помещается в распределенную очередь (распределенная очередь из-за балансировки нагрузки и высокой доступности) с содержимым сообщения, fromUserId, toUserId. Мой вопрос, как будет уведомлен правильный сервер (в данном случае веб-сервер 2)? потому что, если я использую очередь JMS, только один сервер будет уведомлен через прослушиватель. Если я использую тему, все серверы будут уведомлены. В этом случае все серверы могут отклонить сообщение, кроме одного сервера, на котором находится fromUserId. Есть ли лучший способ, когда очередь просто уведомляет правильный сервер на основе некоторых метаданных?
Также, если destinationUserId находится в автономном режиме, мне нужно вернуть сообщение в очередь. Не знаете, как этого можно достичь? Я считаю, что нам нужно использовать какую-то другую реализацию очереди (возможно, очередь в памяти на основе Java) вместо очереди/темы JMS? Код сервера удалит сообщение из пользовательской очереди только после получения подтверждения от клиента.
Если какой-либо клиент находится в автономном режиме во время отправки сообщения, в этом случае, когда он подключается к сети, он отправит запрос на извлечение. Сервер сделает запрос в распределенную очередь, распределенная очередь извлечет сообщение из правой физической очереди. Мой вопрос заключается в том, должна ли распределенная очередь сохранять целевые идентификатор пользователя и сообщение как значение в метаданных?
БД против очереди: - Я считаю, что при таком подходе нет необходимости хранить сообщение в БД, что может быть дорогостоящим (сложность по времени), чем очередь (очередь в памяти) в приложении с высокой степенью реального времени, таком как мессенджер. . Нам просто нужно сохранить информацию о пользователе/группе в db.
Обновление: – я нашел связанную ссылку на quora где последний пункт, т.е. What protocol is used in Whatsapp app ?... от Kah Seng Tay, также подтверждает аналогичный подход с использованием queue , но все же на мои вышеприведенные вопросы об queue еще предстоит ответить.
