Struchkov Mark
7d78047f43
3.6 KiB
| aliases | tags | date | |
|---|---|---|---|
|
2024-11-13 |
WebSocket-соединение, в отличие от Representation State Transfer, имеет состояние, которое представлено объектом класса Session. Это создает трудности при горизонтальном масштабировании.
Представим, что наш сервис чатов развернут в Kubernetes с 3 репликами. Пользователь чата открывает три вкладки браузера с нашим онлайн-чатом. highload/Балансировка нагрузки, использующий алгоритм round robin, распределяет соединения между тремя репликами, и каждое соединение (каждая вкладка) попадает на свою реплику.
Проблема заключается в том, что ==каждая реплика знает только о своих подключениях и не имеет информации о подключениях других реплик==. Если кто-то отправляет новое сообщение на первую реплику, пользователь увидит это сообщение только в той вкладке, которая подключена именно к этой реплике.
Есть несколько способов решить проблему масштабирования для сервисов, использующих WebSocket. Основные варианты включают:
- Не предпринимать никаких действий. В некоторых приложениях строгая синхронизация между WebSocket-соединениями не требуется. Например, ==если ваше приложение только принимает сообщения или отправляет данные для всех пользователей, и вам не важно, из какой реплики они отправляются, возможно, нет необходимости решать эту проблему.==
- Использовать другой алгоритм балансировки. Вы можете настроить балансировку так, чтобы все соединения одного и того же чата всегда направлялись на одну и ту же реплику. Это может вызвать менее равномерное распределение нагрузки, но решит проблему синхронизации между репликами.
- Тонкий Websocket клиент
Мета информация
Область:: ../../meta/zero/00 HighLoad Родитель:: architecture/highload/Горизонтальное масштабирование Источник:: Создана:: 2024-11-13 Автор::