Matrix Synapse - федерация и воркеры

Admin

Содержание

Admin

Вся «магия» федерации и распределения нагрузки происходит на уровне протокола Matrix и реализуется домашними серверами (homeservers), такими как Synapse, Dendrite или Conduit.
В отличие от традиционных централизованных систем (как Telegram или WhatsApp), где нагрузка балансируется внутри закрытого кластера серверов одной компании, в Matrix нагрузка распределяется децентрализованно между серверами всех участников общения.
Вот подробный разбор того, как это работает:

Принцип «Реплицируемых баз данных»
В федерации Matrix нет «главного» сервера для чата. Каждая комната (Room) — это не место на одном диске, а распределенная база данных, копия которой хранится на каждом сервере, чьи пользователи участвуют в этой комнате.
Как распределяется нагрузка:

Сетевая нагрузка: Когда пользователь сервера A отправляет сообщение в общую комнату, сервер A должен отправить (push) это событие на серверы B, C и D, если там есть участники этой комнаты.
Хранение данных: Каждый сервер хранит полную историю сообщений и состояние комнаты (список участников, права), но только для тех комнат, где есть его локальные пользователи.

Топология Full Mesh (Полносвязная сеть)
Нагрузка в федерации распределяется по принципу «каждый с каждым» в контексте конкретной комнаты.
Если в комнате находятся 100 пользователей, и все они «сидят» на разных серверах:

Отправка одного сообщения потребует от сервера отправителя сделать 99 исходящих запросов.
Каждый из 99 серверов-получателей должен принять запрос, проверить цифровую подпись и сохранить событие.
Вывод: Нагрузка на конкретный сервер прямо пропорциональна количеству других серверов, участвующих в комнатах вместе с вашими пользователями.

Основные факторы нагрузки (CPU и RAM)
В федерации Matrix нагрузка ложится на сервер неравномерно и зависит от нескольких специфических процессов:
А. Разрешение состояний (State Resolution)
Это самая ресурсоемкая часть. Поскольку сеть децентрализована, разные серверы могут видеть состояние комнаты по-разному в моменты временных разрывов связи (network partitions).

Когда связь восстанавливается, серверы должны договориться о единой версии правды (кто админ, кого забанили, порядок сообщений).
Нагрузка: Это требует сложных математических вычислений на графах событий (DAG — Directed Acyclic Graph). Чем больше серверов и чем активнее комната, тем выше нагрузка на CPU при синхронизации.
Б. Обработка входящих транзакций (Inbound Federation)
Когда ваш сервер получает сообщение извне:
Проверка подписи: Нужно криптографически верифицировать, что сообщение действительно пришло от заявленного сервера (Ed25519 signatures).
Авторизация: Проверить, имел ли право этот пользователь писать в эту комнату согласно текущим правилам.
В. Join / Leave (Вход и выход)
При входе пользователя в огромную федеративную комнату (например, Matrix HQ с тысячами серверов), ваш сервер должен запросить и обработать огромное количество данных о текущем состоянии комнаты («state events»), что вызывает всплеск нагрузки на RAM и I/O.

Вертикальное и горизонтальное масштабирование (Внутри одного сервера)
Если ваш домашний сервер (например, Synapse) становится узким местом из-за активной федерации, нагрузка распределяется уже архитектурно внутри вашей инфраструктуры:

Монолитный режим: Все процессы (клиентский API, федерация, синхронизация) обрабатывает один процесс Python. Это быстро упирается в потолок производительности одного ядра CPU.
Режим воркеров (Workers): Вы можете вынести обработку федерации на отдельные процессы.
- Federation Sender: Отдельные воркеры, которые только и делают, что рассылают исходящие сообщения другим серверам.
- Federation Reader: Воркеры, принимающие входящий трафик от других серверов.
  Это позволяет балансировать нагрузку от федерации на разные ядра процессора или даже разные физические машины.
  Сводная таблица распределения

Тип действия	Кто несет нагрузку?
Хранение истории	Каждый сервер хранит свою копию истории для своих пользователей.
Доставка сообщения	Сервер-отправитель тратит ресурсы на рассылку всем участвующим серверам.
Прием сообщения	Сервер-получатель тратит ресурсы на проверку подписей и прав доступа.
Шифрование (E2EE)	Клиент (Element). Серверы передают зашифрованные блоки, не тратя CPU на шифрование, но хранят ключи в зашифрованном виде.

Резюме
В федерации Matrix нагрузка не «балансируется» кем-то сверху. Она дублируется.
Если вы администрируете сервер, ваша нагрузка зависит не только от числа ваших пользователей, но и от того, в насколько крупных и активных федеративных комнатах они сидят. Один пользователь, вступивший в комнату с 20 000 участниками с 500 разных серверов, создаст вашему серверу гораздо больше работы, чем 100 пользователей в локальном чате.

Admin

Изоляция, внешний трафик и сервера-воркеры

Про изоляцию и внешний трафик
Если пользователи разных серверов не общаются друг с другом, то трафик между серверами не расходуется. То есть, чужие сервера не будут общаться с вашим сервером, если пользователи чужих серверов не общаются с вашими пользователями. То есть, переживать о том, что чужие сервера будут замусоривать ваш сервер, в этом случае не стоит.
Ещё раз - если ваши пользователи общаются только друг с другом (внутренние комнаты) и не вступают в комнаты на других серверах (например, matrix.org), то ваш сервер работает в режиме изоляции.

Входящий трафик: Чужие серверы не будут стучаться к вам, так как им незачем присылать вам обновления комнат (events).
Безопасность ресурсов: Вы защищены от DDOS-атак через протокол федерации (нагрузка от огромных чатов). Ваш сервер будет потреблять ресурсы только пропорционально активности ваших сотрудников.

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

«Сервера-Воркеры» (Workers)
Воркеры — это не «специальные внешние серверы», которые кто-то предоставляет, чтобы забрать у вас нагрузку. Это часть вашего же программного обеспечения, запущенная на вашем же железе.
Почему они нужны?
Серверная часть Matrix (особенно самая популярная — Synapse) написана на Python. Исторически она работает как один большой процесс (Monolith).

Проблема: Один процесс может эффективно использовать только одно ядро процессора (CPU Core). Даже если у вас мощный сервер с 64 ядрами, Synapse в режиме монолита будет грузить одно ядро на 100%, а остальные 63 будут простаивать, пока чат тормозит.
Что делают воркеры?
Воркеры (Synapse Workers) позволяют разбить этот один большой процесс на много маленьких и раздать их разным ядрам процессора.
Главный процесс: Управляет записью в базу данных.
Воркер-отправщик: Занимается только отправкой данных наружу.
Воркер-читатель: Занимается только обработкой входящих запросов клиентов.
Аналогия:
Представьте, что Монолит — это повар, который сам принимает заказ, сам готовит, сам моет посуду и сам выносит еду. Очередь растет.
Воркеры — это когда вы нанимаете помощников на ту же кухню: один только моет (Media Worker), другой только принимает заказы (Client Reader), третий разносит еду (Federation Sender).
Итоговая картина

Утверждение	Пояснение
Нет общения с чужими — нет нагрузки извне.	Ваш сервер будет «невидим» для федерации, пока вы сами не начнете общаться с внешним миром.
Воркеры — это процессы.	Это процессы на вашем сервере, которые позволяют утилизировать всё ваше железо (все ядра CPU), а не упереться в одно ядро.

Рекомендация
Если вы планируете закрытый корпоративный мессенджер на 50–500 человек без выхода наружу (без федерации), вам не нужно беспокоиться о сложной настройке воркеров сразу. Один стандартный процесс Synapse (монолит) легко справится с такой локальной нагрузкой.

Admin

Воркеры уже есть в стандартной поставке. Вам не нужно скачивать или устанавливать никаких дополнительных плагинов или отдельных версий Synapse.
Это тот же самый программный код, который просто запускается с другими параметрами.
Однако, чтобы переключить Synapse из режима «Монолит» в режим «Воркеры», вам потребуется установить один дополнительный системный компонент — Redis.
Вот как это выглядит технически:

Программная часть (Synapse)
Внутри установленного пакета matrix-synapse уже лежат все необходимые скрипты.

В обычном режиме вы запускаете один главный процесс Synapse.
В режиме воркеров вы запускаете тот же самый Synapse несколько раз параллельно, но каждому процессу скармливаете свой файл конфигурации (например: worker-sender.yaml, worker-reader.yaml).

Аналогия: Это как веб-браузер. Вы устанавливаете его один раз, но можете открыть много вкладок. Воркеры — это как открытие дополнительных вкладок (процессов) для выполнения разных задач, используя одну и ту же установленную программу.

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

Redis: Обязателен. Это быстрая база данных в оперативной памяти. Через нее главный процесс и воркеры общаются друг с другом мгновенно.
Балансировщик нагрузки (Nginx, HAProxy): Он, скорее всего, у вас уже есть (как обратный прокси), но его настройки придется усложнить. Он должен знать: «Ага, запрос на отправку файла — шлю на воркер №1, а запрос на чтение чата — на воркер №2».

Если вы используете Docker
Если вы разворачиваете сервер через Docker, это еще нагляднее:
Вы используете один и тот же образ (image) matrixdotorg/synapse.
Просто в docker-compose.yml вы прописываете этот образ несколько раз: один раз как "master", и несколько раз как "worker", передавая разные настройки.
Резюме

Скачивать Synapse заново не надо. Воркеры уже внутри.
Нужно установить Redis (системный пакет).
Сложность не в установке, а в настройке. Вам придется разбить один файл конфигурации homeserver.yaml на несколько частей и настроить маршрутизацию в Nginx.

Admin

Масштабирование и выбор базы данных

Выбор базы данных — это самое критичное решение на этапе установки. Сменить процессор или добавить оперативную память можно легко, а вот сменить базу данных на живом сервере с перепиской — это больно, долго и рискованно.
Вот почему для Synapse (особенно с прицелом на воркеры) PostgreSQL обязателен, а SQLite — тупиковый путь.

Фундаментальное различие: Файл против Сервера
Чтобы понять проблему, давайте представим базу данных как журнал учета посетителей.
SQLite (Как это работает)
SQLite — это просто один файл на диске.

Аналогия: Это бумажный журнал, лежащий на столе.
Проблема: Если вы (основной процесс Synapse) что-то в него пишете, вы физически забираете журнал к себе. Если в этот момент приходят 5 помощников (воркеров), они не могут ничего записать. Они стоят в очереди и ждут, пока вы положите журнал обратно.
Результат для воркеров: Воркеры технически несовместимы с SQLite. Synapse просто не запустится в режиме воркеров с SQLite, потому что архитектура воркеров подразумевает, что много процессов одновременно читают и пишут в базу.
PostgreSQL (Как это работает)
PostgreSQL — это клиент-серверная система.
Аналогия: Это электронная система учета с командой архивариусов.
Преимущество: Вы и ваши 5 помощников (воркеров) посылаете запросы одновременно. Система сама разруливает их: "Ты пиши в строку 5, ты читай строку 10, а ты создавай новую таблицу".
Результат: Никто никого не ждет. Производительность растет линейно с добавлением ресурсов.

Почему нельзя переехать "потом"?
Многие администраторы думают: "Я сейчас подниму на SQLite, потому что это просто (не надо настраивать юзера/пароль базы), а если нагрузка вырастет — перееду на Postgres".
Это ловушка по двум причинам:

Сложность миграции: В Matrix база данных хранит сложнейший граф событий (DAG). Скрипт переноса данных из SQLite в Postgres существует (synapse_port_db), но на больших базах (гигабайты истории) он может работать часами, требуя полной остановки сервера.
Риск потери данных: Любой сбой при конвертации типов данных может привести к тому, что старая переписка станет нечитаемой или сервер перестанет синхронизироваться.

Производительность даже без воркеров
Даже если вы используете Монолит (один процесс) и не планируете включать воркеры завтра:

SQLite начинает "захлебываться" (ошибка Database is locked), если в чате одновременно начинают писать 5-10 человек или если сервер начинает принимать тяжелый файл. Интерфейс у пользователей начинает "тупить".
PostgreSQL держит сотни одновременных соединений даже на слабом железе. Он гораздо лучше использует кэширование в оперативной памяти (RAM).
Итог

Характеристика	SQLite	PostgreSQL
Тип	Файл на диске	Полноценный сервер БД
Поддержка Workers	Нет (Технически невозможно)	Да (Родной режим)
Настройка	Нулевая (само создается)	Требует создания юзера и БД
Надежность	Может побиться при сбое питания	Высокая (ACID, WAL-журналы)
Сценарий	Тесты, личный бот, 1-2 юзера	Продакшн, любой сервер от 5 человек

Главный совет:
Даже если вы запускаете сервер "для друзей", сразу ставьте PostgreSQL.

Admin

Возможность запуска промежуточных серверов, которые всю нагрузку репликации будут брать на себя

Этот вопрос касается архитектурной изоляции.
Короткий ответ: В виде "черного ящика" или простого прокси — нет. Вы не можете поставить какой-то сторонний "глупый" сервер, который просто пережует всю нагрузку и отдаст вам готовый результат.
Развернутый ответ: Да, это возможно через архитектуру тех же Воркеров (Workers), вынесенных на отдельную машину.
Давайте разберем, почему нельзя сделать простой "прокси", и как сделать то, что вы хотите, правильным способом.
Почему нельзя поставить простой "Прокси-сервер"?
В протоколе Matrix федерация — это не просто пересылка байтов (как в Nginx). Это глубокая логическая работа. Чтобы "промежуточный сервер" мог взять на себя нагрузку, он должен обладать двумя вещами, которые есть только у главного сервера:

Криптографические ключи: Чтобы отправить сообщение другому серверу, его нужно подписать приватным ключом вашего домена. Если вы отдадите ключи промежуточному серверу, он фактически станет вами.
Доступ к Базе Данных: Чтобы принять входящее сообщение, сервер должен знать: "А есть ли в этой комнате наши пользователи? Не забанен ли отправитель? Какое предыдущее сообщение в цепочке, чтобы связать их?".
Поэтому "промежуточный сервер" не может быть отдельной сущностью. Он должен быть частью вашего кластера.
Решение: Выделенный сервер федерации (Federation Worker Node)
Вы можете реализовать вашу задумку, используя Synapse Workers, разнесенные по разным физическим серверам.
Вы можете построить архитектуру так, чтобы ваш основной сервер обслуживал только ваших пользователей (быстрый интерфейс, отправка сообщений), а всю "грязь" и тяжесть общения с внешним миром вынести на другую машину.
Как это выглядит (Топология)
Представьте два сервера (физических или VPS):
Сервер А (Main / Client Node) — "Чистая зона"
Задачи: Обслуживает API клиентов (Element), пуш-уведомления.
Нагрузка: Минимальная, только действия ваших сотрудников.
Результат: У пользователей Element "летает", даже если сервер бомбят снаружи.
Сервер Б (Federation Node) — "Грязная зона"
Задачи: Federation Sender (отправка наружу) и Federation Reader (прием извне).
Нагрузка: 100% всей тяжести репликации, проверки подписей, разрешения конфликтов JSON.
Связь: Этот сервер соединяется с Сервером А через внутреннюю сеть (VPN/LAN) для доступа к общей Базе Данных и Redis.
Схема потоков данных
Входящий трафик (из Интернета):
Балансировщик нагрузки (Nginx) видит запрос от чужого сервера (matrix.org) -> Направляет его сразу на Сервер Б.
Сервер А даже не просыпается.
Действия пользователей:
Ваш сотрудник пишет сообщение -> Element соединяется с Сервером А.
Сервер А сохраняет сообщение в БД и говорит через Redis Серверу Б: "Эй, это надо разослать".
Сервер Б начинает потеть, рассылая это по всему миру.
Плюсы и минусы такого подхода

Плюсы	Минусы
Изоляция: Если федерация "положит" CPU на Сервере Б, ваши пользователи на Сервере А этого не заметят. Чат продолжит работать локально.	Сложность сети: Нужно настроить безопасный и быстрый канал (низкий пинг) между Сервером А и Б (так как они долбят одну БД).
Безопасность: Можно настроить Firewall так, что Сервер А вообще не имеет доступа к внешнему интернету, кроме канала до Сервера Б.	Цена: Нужно платить за две машины. Причем Сервер Б (федерация) должен быть мощнее по CPU.

Резюме
Специального "коробочного" софта "Matrix Federation Proxy" не существует.
Но вы можете достичь этой цели, запустив процессы Synapse Federation Workers на отдельной физической машине, подключенной к той же базе PostgreSQL. Это стандартная практика для крупных деплоев (десятки тысяч пользователей), чтобы отделить пользовательский опыт от фоновых шумов интернета.

Admin

Можно ли контролировать, какие пользователи создают внешние комнаты, как публичные, так и приватные?

Да. Контроль над созданием комнат — это стандартная и очень важная административная задача в Synapse.
Это не только вопрос безопасности (чтобы рядовой сотрудник не создал публичный чат от имени вашей компании), но и прямой инструмент для управления той самой нагрузкой от федерации, о которой мы говорили.
Если пользователь не может создать внешнюю комнату, то ваш сервер не присоединится к внешнему миру, и трафик останется локальным.
Как это контролируется в Synapse?
Контроль за созданием комнат регулируется настройками в файле homeserver.yaml и может быть реализован двумя основными способами:

Ограничение для всех, кроме администраторов (Самый простой способ)
Вы можете настроить сервер так, чтобы только пользователи, внесенные в список администраторов или модераторов (у которых есть определенные права), могли создавать комнаты.
Поскольку Matrix не имеет встроенного простого интерфейса для управления этими правами (как в WhatsApp), это делается через настройки сервера.

Как это работает: Вы создаете список доверенных пользователей (например, @admin:myserver.com) и явно разрешаете им доступ к API-вызову createRoom. Для всех остальных пользователей этот API-вызов будет запрещен.
Результат: Рядовые пользователи могут вступать в существующие комнаты и общаться, но не могут создавать новые, которые могут открыть федерацию.

Использование Application Services (Для сложных правил)
Если вам нужны более гибкие правила, например:

Разрешить всем пользователям создавать приватные комнаты, но запретить создавать публичные.
Разрешить создание комнат только пользователям из определенного отдела.
В этом случае администраторы используют Application Services (сервисы приложений) или модули Python.
Вы пишете или используете готовый модуль, который перехватывает запрос на создание комнаты (createRoom).
Этот модуль проверяет:
- Является ли комната публичной?
- Является ли создатель членом группы "Marketing"?
Если правила нарушены, модуль отклоняет запрос до того, как Synapse его обработает.
Контроль внешней (Federated) активности
Важно отметить:
Нет простого способа сказать: "Создать комнату, но только для локальных пользователей и запретить федерацию".
Поэтому лучший способ контроля внешней нагрузки — это контроль над созданием комнаты как таковым.
Если ваш пользователь:
Создает комнату → он может сделать ее публичной, пригласить внешних пользователей и открыть федерацию.
Не может создать комнату → он может только присоединиться к той, которую создали вы (админ), или к внешней комнате, инициированной другим сервером.
Резюме
Для корпоративных или закрытых инсталляций, которые хотят контролировать нагрузку, всегда рекомендуется:
Установить права на создание комнат только для администраторов и модераторов.
Администраторы создают все необходимые комнаты (как локальные, так и внешние).

База знаний (кластер NBICS)

Matrix Synapse - федерация и воркеры

Изоляция, внешний трафик и сервера-воркеры

Масштабирование и выбор базы данных

Возможность запуска промежуточных серверов, которые всю нагрузку репликации будут брать на себя

Можно ли контролировать, какие пользователи создают внешние комнаты, как публичные, так и приватные?