Обмен сообщениями «точка-точка» в масштабируемом приложении?

Хотели бы знать, правильное ли это направление для масштабируемого чат-мессенджера?

Разработка этого приложения с использованием очередей сообщений имеет следующие преимущества:

• Разъединение клиент-сервер и уменьшение количества сбоев: очереди могут изящно справляться с пиками трафика, просто временно увеличивая размер очереди, который вернется к нормальному состоянию, пока трафик снова нормальный (или любые временные сбои были исправлены)
• В приложении для обмена сообщениями клиенты (мобильные устройства) могут находиться в автономном режиме в течение длительного времени. В результате синхронный дизайн не будет работать, поскольку клиенты могут быть недоступны для доставки сообщений. Однако при асинхронном дизайне, как и в случае с очередями сообщений, ответственность за доставку сообщений лежит на стороне клиента. В результате клиент может опрашивать новые сообщения, как только он подключается к сети.

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

Но если у нас есть несколько распределенных очередей, как система обеспечит доставку сообщений FIFO по распределенным очередям?

Многие очереди с открытым исходным кодом (rabbitMQ, activeMQ) или коммерческие (AWS SQS) поддерживают порядок FIFO. Однако гарантии FIFO внутри очереди недостаточно, поскольку сообщения, отправленные одним клиентом, могут быть доставлены в очередь в другом порядке из-за проблем с асинхронностью в сети (если только вы не используете одну нераспределенную очередь и TCP). что гарантирует доставку заказанного товара).

Однако вы можете реализовать упорядочивание FIFO на стороне клиента. Следуя этому подходу, сообщения будут включать метку времени, которая будет использоваться каждым клиентом для сортировки сообщений при их получении. Единственным побочным эффектом этого является то, что клиент может увидеть сообщение, не просматривая сначала все предыдущие сообщения. Однако при поступлении предыдущих сообщений они будут отображаться в пользовательском интерфейсе клиента в правильном порядке, поэтому в конечном итоге пользователь увидит все сообщения и в правильном порядке.

 Would like to know if this is the right direction for scalable chat messenger?

Я бы, наверное, предпочел немного другой подход. Ваши идеи верны, но я хотел бы добавить немного больше к тому же. Мне довелось создать такой чат-мессенджер несколько лет назад, и он должен был быть очень похож на watsapp. Я уверен, что когда вы гуглили, вы бы сталкивались с расширяемым протоколом обмена сообщениями и присутствия XMPP. мы использовали openfire в качестве сервера, поддерживающего соединения. Концепция, которую вы объяснили, где

Say Friend 1 and Friend 2 are online . Friend 1 has established HTTP web connection to web server 1 and Friend 2 has established HTTP web connection to web server 2. Friend 1 send the message to Friend 2.

называется федерацией, и openfire может работать в федеративном режиме. Прочитав ваши комментарии, я наткнулся на одну очередь на точку пользователя. Я уверен, что вы уже знаете, что этот подход не является масштабируемым, так как он очень ресурсоемкий. Хорошим подходом было бы использование фреймворка Актера, такого как akka. Каждый актер похож на легкий поток в Java, и у каждого актера есть почтовый ящик. поэтому в этом случае об обмене сообщениями позаботятся.

Таким образом, ваш сценарий преобразуется в Друг 1, открывает соединение с сервером openfire xmpp и инициализирует актера Друга 1. Когда он набирает сообщение, оно передается в папку «Входящие» актера Друга 1 (у каждого актера в akka есть почтовый ящик в памяти). Это передается на сервер xmpp. У сервера есть собственная база данных, и, поскольку он объединен с другими серверами xmpp, он попытается найти, находится ли друг 2 в сети. Сервер xmpp будет хранить сообщение в своей базе данных до тех пор, пока друг 2 не подключится к сети. Как только друг 2 устанавливает соединение с любым сервером xmpp, создается актер друга 2, и его присутствие распространяется на все остальные серверы, а сервер xmpp 1 уведомляет актера друга 2. Входящие сообщения актера друга 2 теперь будут получать сообщение

Опционально: Существует также возможность получения квитанции о доставке. Как только друг 2 прочитает сообщение, другу 1 может быть отправлена ​​квитанция о доставке, чтобы указать статус сообщения, т. е. прочитано, не прочитано, доставлено, не доставлено и т. д.