Что такое репликация данных в бэкенд-системах? Какие существуют основные подходы и паттерны?

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

Основные подходы к репликации:

1. Leader-Follower (Master-Slave)

   • Как работает: Все запросы на запись (INSERT, UPDATE, DELETE) обрабатываются одним узлом — лидером (мастером). Лидер записывает изменения в свой лог транзакций (например, WAL в PostgreSQL) и рассылает их последователям (репликам). Реплики применяют эти изменения к своим копиям данных.
   • Плюсы: Простая и понятная модель консистентности. Отлично подходит для систем с преобладанием операций чтения.
   • Минусы: Лидер является единой точкой отказа. Возможна задержка репликации (replication lag), когда реплики отстают от лидера.
   • Примеры: PostgreSQL Streaming Replication, MySQL Replication.

2. Multi-Leader (Master-Master)

   • Как работает: Несколько узлов могут принимать запросы на запись. Каждый лидер реплицирует свои изменения другим лидерам и их последователям.
   • Плюсы: Повышенная доступность на запись (система работает, даже если один из лидеров недоступен). Хорошо подходит для геораспределенных систем.
   • Минусы: Главная сложность — разрешение конфликтов записи, когда одни и те же данные изменяются на разных лидерах одновременно. Для этого используются стратегии вроде "Last Write Wins" (LWW) или более сложные CRDT (Conflict-free Replicated Data Types).

3. Peer-to-Peer (Leaderless)

   • Как работает: Все узлы равноправны, любой узел может принимать запросы на запись и чтение. Для обеспечения консистентности используются кворумы.
   • Принцип кворума: При записи данных система должна получить подтверждение от W узлов, а при чтении — от R узлов. Если W + R > N (где N — общее число реплик), мы гарантированно получим актуальные данные при чтении.
   • Плюсы: Высокая доступность и отказоустойчивость, нет единой точки отказа.
   • Минусы: Более сложная логика для достижения консистентности. Возможны устаревшие чтения, если кворум не настроен строго.
   • Примеры: Cassandra, DynamoDB, Riak.

В Go для построения распределенных систем часто используются готовые решения, реализующие эти паттерны, например, библиотеки на основе алгоритма консенсуса Raft (etcd, Consul).