Идеи для масштабирования чата в AWS?

Я пытаюсь найти лучшее решение для масштабирования службы чата в AWS. Я придумал пару возможных решений:

  • Redis Pub/Sub - когда пользователь устанавливает соединение с сервером, который сервер подписывается на этот идентификатор пользователя. Когда кто-то отправляет сообщение этому пользователю, сервер будет выполнять публикацию на канале с идентификатором пользователя. Сервер, к которому подключен пользователь, получит сообщение и нажмет его на соответствующий клиент.

  • SQS - Я думал о создании очереди для каждого пользователя. Сервер, к которому подключен пользователь, будет опросить (или использовать длительный опрос SQS) в очереди. Когда новое сообщение будет обнаружено, оно будет перенаправлено пользователю с сервера.

  • SNS - мне действительно понравилось это решение, пока я не узнал 100 ограничений темы. Мне нужно создать тему для каждого пользователя, которая будет поддерживать только 100 пользователей.

Можно ли их использовать в других чатах, используя AWS? Является ли подход SQS жизнеспособным? Сколько времени требуется AWS для добавления сообщения в очередь?

ОТВЕТЫ

Ответ 1

Построение чат-сервиса не так просто, как вы думаете.

Я построил полноценные XMPP серверы, клиенты и SDK и может подтвердить некоторые из тонких и сложных проблем, которые возникают. Прототип, где пользователи видят друг друга и чат легко. Полная система функций с созданием учетных записей, безопасностью, открытием, присутствием, автономной доставкой и списками друзей намного сложнее. Для того, чтобы масштабировать это на любом количестве серверов, особенно сложно.

PubSub - это функция, предлагаемая службами чата (см. XEP-60), а не традиционный способ создания чат-сервиса. Я вижу соблазн, но PubSub может иметь недостатки.

Некоторые вопросы для вас: 1. Вы делаете это через Интернет? Могут ли пользователи подключаться и долго работать или у вас есть решение для веб-сокетов?

  1. Сколько пользователей? Сколько соединений на пользователя? Соотношение записей для чтения?

  2. Ваша идея использования SQS в этом случае интересна, но, вероятно, не будет масштабироваться. Это не необычно, если на чат-сервере есть 50 или более пользователей. Если вы запрашиваете каждую очередь SQS для каждого пользователя, вы не собираетесь приближаться к ней. Вам будет лучше иметь очередь для каждого сервера, и сервер опросит только эту очередь. Затем вам нужно выяснить, на каком сервере находится пользователь, и поместить сообщение в нужную очередь.

Я подозреваю, что вы захотите сделать что-то вроде:

  • Большая база данных RDS на бэкэнд.
  • Множество интерфейсных серверов, обрабатывающих клиентские соединения.
  • Некоторый код Java/С# среднего уровня отслеживает все и направляет сообщения в нужное место.

Чтобы получить представление о сложности создания чат-сервера, прочтите XMPP RFC: RFC 3920 RFC 3921

Ответ 2

SQS/SNS может не соответствовать вашему требованию. мы наблюдали некоторую задержку в SQS, которая может не подходить для приложения чата. Также SQS не гарантирует FIFO. Я работал с Redis на AWS. Он довольно прост и стабилен, если он настроен с учетом всех лучших практик.

Ответ 3

Я думал о создании чат-сервера с использованием SNS, но вместо того, чтобы описывать одну тему для каждого пользователя, делая одну тему для всей системы чата и каждый из которых подписывается на эту тему - где работает каждый сервер какой-то длинный опрос или веб-чаты. Затем, когда происходит событие, данные отправляются в полезной нагрузке уведомления SNS. Затем сервер может использовать эту полезную нагрузку, чтобы определить, какие клиенты в своей очереди должны получить ответ, оставив без привязанности не связанных между собой клиентов. Я на самом деле построил небольшой прототип для этого, но не провел тонну тестирования, чтобы убедиться, достаточно ли он достаточно для большого количества пользователей.

Ответ 4

способ реализовать такую ​​вещь (если не использовать некоторую фреймворк) заключается в следующем:

имеет веб-сервер (на ec2), который принимает сообщения от пользователя. используйте группу Autoscalling на этом веб-сервере. веб-сервер может обновлять любую БД на Amazon RDS, которая может масштабироваться легко.

Если вы используете свой собственный db, вы можете рассмотреть возможность отделить db от веб-сервера с помощью sqs (отправив все запросы в одну очередь), а затем u может иметь потребитель, который потребляет очередь. этот потребитель также может быть помещен за группу автосохранения, так что если очередь больше X msgs, она будет масштабироваться (вы можете настроить ее с помощью сигналов тревоги)

sqs обычно обновляются довольно быстро, т.е. менее одной секунды. (с момента, когда u отправил его, до момента его появления в очереди), и редко более того.

Ответ 5

С тех пор как новая служба AWS IoT начала поддерживать WebSockets, Keepalive и Pub/Sub пару месяцев назад, вы можете легко создать на ней эластичный чат. AWS IoT - это управляемая служба с большим количеством SDK для разных языков, включая JavaScript, который был создан для обработки монстров (миллиарды сообщений) с нулевым администрированием.

Подробнее об обновлении можно узнать здесь:

https://aws.amazon.com/ru/about-aws/whats-new/2016/01/aws-iot-now-supports-websockets-custom-keepalive-intervals-and-enhanced-console/

Edit:

Последнее обновление SQS (2016/11): теперь вы можете использовать Amazon Simple Queue Service (SQS) для приложений, которые требуют обработки сообщений в строгой последовательности и ровно один раз с использованием очередей First-In, First-out (FIFO), Очереди FIFO предназначены для обеспечения строгого сохранения порядка, в котором отправляются и принимаются сообщения, и что каждое сообщение обрабатывается ровно один раз.

Источник: https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/

Теперь реализация SQS + SNS также выглядит хорошей идеей.

Ответ 6

HI чат реального времени не работает с SNS. Он предназначен для электронной почты /SMS или услуг 1 или нескольких секунд ожидания. В чате реального времени 1 или несколько секунд не.

проверить эту ссылку

Latency (i.e. "Realtime") for PubNub vs SNS

Amazon SNS не обеспечивает никаких латентных гарантий, и подавляющее большинство задержек измеряются в течение 1 секунды, а часто на несколько секунд медленнее. Опять же, это несколько не имеет значения; Amazon SNS предназначена для уведомлений от сервера к серверу (или электронной почты /SMS ), где часто бывает приемлемой и ожидаемой латентность многих секунд.

Поскольку PubNub предоставляет данные через существующий установленный открытый сетевой сокет, задержки находятся в пределах 0,25 секунды от публикации для подписки в 95% процентиле подписных устройств. Большинство людей воспринимают что-то как "в реальном времени", если событие воспринимается в течение 0,6 - 0,7 секунды.