Какие бывают схемы репликации и чем они отличаются?

Зачем реплицировать: отказоустойчивость (данные переживают потерю машины), масштабирование чтения, данные ближе к пользователям.

Один лидер (leader–follower, primary–replica). Клиенты пишут в лидера; он применяет изменение и шлёт поток изменений (журнал) репликам. Читать можно с лидера или реплик. Плюсы — простота, порядок записей задан лидером, конфликтов нет. Минусы:

• запись не масштабируется — она вся на одной машине (тогда шардирование: у каждого шарда свой лидер);
• failover при падении лидера: обнаружить, выбрать новый, перенастроить клиентов — и не получить двух лидеров (split brain);
• отставание реплик при асинхронной репликации.

Несколько лидеров (multi-leader). Лидер в каждом дата-центре, изменения обмениваются между ними асинхронно. Запись быстрая и локальная, регион работает при потере связи. Но два региона могут одновременно изменить одну запись — конфликт. Разрешение: «последняя запись побеждает» по времени (теряет данные), слияние по правилам приложения, CRDT — структуры данных, которые сливаются без конфликтов (счётчики, множества, документы для совместного редактирования). Ещё сценарий — офлайн-клиенты: телефон с локальной копией, который потом синхронизируется.

Без лидера (leaderless, в стиле Dynamo). Клиент или координатор отправляет запись на все N реплик и ждёт W подтверждений; чтение спрашивает R реплик и берёт самую свежую версию. При W + R > N множества пересекаются, и чтение увидит хотя бы одну реплику с последней подтверждённой записью. Типично N = 3, W = 2, R = 2. Отстающие реплики догоняют через read repair (при чтении) и anti-entropy (фоновая сверка деревьями Меркла); при временном отказе узла запись принимает другой узел и потом передаёт её (hinted handoff). Нет failover — нет и паузы при отказе. Но кворум не даёт линеаризуемости, а одновременные записи разрешаются версиями или «последний побеждает».

Как выбирать: обычная транзакционная база — один лидер плюс реплики; активная работа в нескольких регионах — мульти-лидер или специальные распределённые базы (Spanner, CockroachDB, YugabyteDB — консенсус на каждый шард); высокая доступность записи и терпимость к итоговой согласованности — безлидерная (Cassandra, ScyllaDB, DynamoDB).

Cassandra, N=3 (RF=3):
  запись CONSISTENCY QUORUM → ждём 2 из 3
  чтение CONSISTENCY QUORUM → спрашиваем 2 из 3, берём самую свежую по timestamp
  W + R = 4 > 3 — чтение пересекается с записью
  CONSISTENCY ONE для записи и чтения: 1 + 1 = 2 ≤ 3 — можно прочитать старое