Разработка крупномасштабной системы веб-сокетов, поддерживающей TCP-соединения - PullRequest
2 голосов
/ 25 октября 2019

Скажем, у вас очень большая система (сотни миллионов пользователей активны в любой момент), и вам нужно активно передавать сообщения / уведомления с серверов на конечную точку их клиента. Привычно ли иметь несколько тысяч машин, выделенных для удержания TCP-соединения с активными пользователями?

Если это так, я бы предположил, что впереди стоит «служба поиска» из тех машин, которые решают, какой user_id должен быть подключен к какой машине (например: с использованием хеш-функции, которая отображает user_id в server_id), верно?

Мой вопрос такой:Насколько велики такие системы, как слой уведомлений Facebook / Twitter? При использовании большого количества машин, предназначенных для хранения TCP-соединений, и впереди есть служба поиска, которая сопоставляет user_id с server_id? Если да, то как они справляются со случаем сбоя сервера ? И что происходит, когда вам нужно добавить больше серверов , так как номера серверов меняются, не нужно ли нам повторно хэшировать всех пользователей?

Спасибо!

1 Ответ

0 голосов
/ 26 октября 2019

Есть много разных подходов к этому, но все они сводятся к технике «разделяй и властвуй».

Эти методы делят сеть на «зоны», где каждая «зона» отвечает за подмножество данных / сети.

Эти «зоны» могут быть дополнительно подразделены на более мелкие«зоны», позволяющие дальнейшее масштабирование по мере необходимости.

Каждый конечный узел в этом дереве «зон» может содержать целый стек компьютеров (балансировщики нагрузки, кэширование (т. е. memcache), базы данных или конечную точку API),в зависимости от требований к приложению.

Одной из причин популярности AWS является то, что он предоставляет инструменты, которые делают многое из этого, облегчая управление масштабируемостью.

Это зависит от вашего использования. -case, но имеет смысл разделить зоны географически (рассмотрим, как работают CDN).

Например, приложение можно разделить на зоны на континент, т. е. Азию, Европу, Америку, Африку, Океанию,и т. д.

Каждая из этих зон может быть разделена далее по стране / штату.

В некоторых штатах может потребоваться несколько (под) зон из-за интенсивного движения (ird (уровень маршрутизации / перенаправления).

Каждая из этих подзон будет содержать собственный (под) домен, балансировщик нагрузки и несколько компьютеров, которые управляют как соединениями, так и данными для этой зоны.

Этот пример географического разделения может (теоретически) минимизировать сетевой трафик и задержку за счет географической ориентации ответов DNS. Это позволит (например) для трафика Нью-Йорка оставаться в Нью-Йорке, если не требуется «трансграничная» связь.

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

Это, очевидно, имеет ряд сложностей. Например: что если пользователь из США путешествует по Великобритании? мы перемещаем его данные в другую зону или маршрутизируем соединение с сервером США со всеми вытекающими задержками? ...

Однако, в конце концов, нет другого выбора, кроме как "разделяй и властвуй". Даже базы данных не могут хранить все данные на одном компьютере, и данные должны быть разделены на подмножества в разных базах данных.

Кроме того, некоторые данные (например, назначения зон) очень трудно разделить. Некоторые данные настаивают на том, чтобы быть «глобальными» (например, как мы узнаем, к какой зоне принадлежит пользователь?) ... Здесь часто используются хэш-значения.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...