Репликация баз данных в высоконагруженных сервисах

Репликация данных — процесс синхронного или асинхронного копирования изменений с одного узла базы данных (мастера) на один или несколько подчинённых узлов (реплик). В высоконагруженных системах репликация используется для:

• Масштабирования операций чтения — распределение запросов SELECT по репликам.
• Обеспечения отказоустойчивости — при выходе из строя мастера реплика берёт на себя его функции.
• Географической распределённости — приближение данных к пользователям разных регионов.
• Обслуживания аналитических отчётов без влияния на операционную нагрузку.

1. Основные стратегии репликации

1.1. Master‑Slave (Single‑Leader)

• Один узел (master) принимает все операции записи и передаёт изменения на одну или несколько реплик (slave).
• Реплики обслуживают запросы на чтение.
• Плюсы: простота, отсутствие конфликтов записи, линейное масштабирование чтения.
• Минусы: мастер остаётся единой точкой для записи; возможна задержка репликации (replica lag).

1.2. Multi‑Master (Multi‑Leader)

• Несколько узлов могут принимать запись, изменения реплицируются между ними.
• Синхронная: транзакция подтверждается только после применения на всех мастерах — высокая согласованность, но задержки.
• Асинхронная: выше производительность, но возможны конфликты.
• Применяется в географически распределённых кластерах (например, двухцентровые решения).

1.3. Каскадная репликация

• Реплики могут выступать источниками для других реплик, образуя дерево.
• Позволяет снизить нагрузку на мастер при большом количестве реплик.

1.4. Репликация с шардингом

• Данные разделены на шарды (партиции), каждый шард имеет свой мастер и реплики.
• Комбинация шардинга и репликации — стандарт для горизонтального масштабирования.

1.5. Особенности NoSQL

• Cassandra: peer‑to‑peer, все узлы равны, настраивается уровень согласованности (QUORUM, ONE и т.д.).
• MongoDB: replica set (один primary, несколько secondary) + шардинг.

2. Примеры известных проектов

• Instagram — использовали PostgreSQL с master‑slave репликацией, затем перешли на шардинг по ID пользователей с отдельными кластерами master‑replica для каждого шарда.
• Twitter — ранняя архитектура на MySQL с master‑slave, где чтение твитов шло с реплик, а запись в мастер. Позже внедрили Cassandra для более линейной масштабируемости.
• Uber — применяли PostgreSQL с ручным шардингом и репликацией; каждый шард имел свой мастер и несколько реплик для чтения геоданных и истории поездок.
• Facebook — исторически MySQL с асинхронной репликацией, позже для чата внедрили собственное решение на базе Cassandra с репликацией между датацентрами.
• Google Spanner — глобально распределённая БД с синхронной multi‑master репликацией и консенсусом Paxos.

3. Применение для онлайн‑чата (нагрузка >50k RPS)

Онлайн‑чат предъявляет специфические требования:

• высокая интенсивность записи (новые сообщения, статусы);
• частые чтения (история диалогов, списки контактов);
• низкая задержка (real‑time доставка);
• согласованность порядка сообщений.

Как репликация помогает

• Реплики для чтения истории: все запросы на просмотр истории направляются на реплики, мастер занимается только записью новых сообщений. Это позволяет выдерживать асимметричную нагрузку (чтений обычно больше, чем записей).
• Отказоустойчивость: при падении мастера одна из реплик повышается до мастера (автоматически или вручную), сервис продолжает работу.
• Географическая распределённость: если чат используется по всему миру, можно разместить мастер в одном регионе, а реплики в других для локального чтения истории. Либо использовать multi‑master с разрешением конфликтов (например, на основе векторных часов).

Архитектура для >50k RPS

• Шардинг — обязателен. Сообщения распределяются по шардам, например, по идентификатору чата (или пользователя). Каждый шард — отдельный кластер master‑replica.
• Каждый шард: 1 мастер (запись) и 2–3 реплики (чтение). Общее количество RPS распределяется по шардам. Если 50k RPS — это суммарная нагрузка, при 10 шардах каждый обрабатывает ~5k RPS, что легко.
• Для записи в пределах шарда используется мастер; при необходимости можно включить синхронную репликацию на одну из реплик для гарантии непотери сообщения (но это увеличит задержку). Компромисс: асинхронная репликация с подтверждением записи в WAL мастера.
• Кэширование последних сообщений (например, Redis) снижает нагрузку на реплики, но репликация остаётся основой долговременного хранения.

4. Обеспечение нагрузки свыше 50k RPS

Достижение 50k RPS возможно только при грамотном сочетании шардинга и репликации:

1. Шардирование данных — разбиение по ключу (user_id, chat_id) так, чтобы запись и чтение конкретного чата попадали в один шард. Это исключает распределённые транзакции.
2. Репликация внутри шарда — каждый шард имеет свой мастер и реплики. Мастер обрабатывает запись (Insert/Update), реплики — чтение (Select).
3. Балансировка чтения — запросы на чтение распределяются между репликами шарда через балансировщик (например, HAProxy, ProxySQL) или на стороне приложения.
4. Мониторинг лага репликации — при большой нагрузке на запись реплики могут отставать. Используются асинхронные реплики с возможностью временного переключения чтения на мастер для критичных данных (например, свежие сообщения самого пользователя).
5. Автоматическое переключение мастера — при сбое мастера реплика повышается (Promotion), приложение переключает запись на новый мастер.

В системах, где 50k RPS — это в основном чтение (например, история сообщений), можно обойтись 1 мастером и несколькими десятками реплик. Но если и запись достигает десятков тысяч RPS, без шардинга не обойтись.

5. Заключение

Выбор стратегии репликации зависит от требований к согласованности, доступности и задержкам. Для высоконагруженного онлайн‑чата оптимальной является комбинация шардинга (по идентификатору чата/пользователя) и классической master‑slave репликации внутри каждого шарда. Такой подход позволяет горизонтально масштабировать систему под любую нагрузку, сохраняя приемлемую сложность эксплуатации и предсказуемое поведение при сбоях.

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot
Подпишись на https://t.me/LyakhovEugene