Краткая архитектура (цель — выдерживать потерю одного узла без потери данных, сильная согласованность):
- Топология:
- Разделение данных на шарды (consistent hashing / range shards). Каждый шард имеет репликационный набор размером $N=3$ (трёхкопийное хранение).
- Реплики шарда размещаются по разным физическим хостам/сторам и по разным стойкам/ошаровым зонам (rack/zone awareness).
- Репликация и консенсус:
- Для каждого шарда запускается независимая группа Raft (или Multi-Paxos), размер группы $N=3$. Raft обеспечивает выбор лидера, репликацию журнала и линейную согласованность.
- Ключевое свойство: большинство = $\lfloor N/2\rfloor +1$. При $N=3$ большинство = $2$ — потеря одного узла сохраняет большинство и возможность коммитить записи.
- Запись: клиент → лидер шарда. Лидер записывает в WAL, реплицирует log-entries фоловерам; ответ клиенту после подтверждения большинства (commit).
- Чтение: по умолчанию через лидера (линейная консистентность). Опционально можно использовать ReadIndex / lease-reads для уменьшения задержки, с оговорками по корректности при смене лидера.
- Параметры кворума (альтернатива Raft):
- Если используется quorum-replication: $N=3,W=2,R=2$. Условие для сильной консистенции: $W+R>N$ (здесь $2+2>3$).
- Надёжность и целостность данных:
- WAL + периодические snapshot'ы состояния для быстрой подгрузки при восстановлении.
- Контроль целостности (контрольные суммы на сегменты/объекты).
- Фоновые anti-entropy процессы (Merkle-деревья) для обнаружения и исправления расхождений.
- Обнаружение и реакция на отказ:
- Heartbeats/timeouts в Raft обнаруживают упавшего узла. Если падение временное — группа продолжает работу с оставшимися репликами.
- При устойчивом отсутствии узла: orchestration (контроллер) инициирует создание замещающей реплики на другом хосте для восстановления $N=3$.
- Репликация новой ноды: сначала snapshot (если log слишком длинный) + затем apply оставшихся логов; при необходимости — инкрементальная синхронизация. Время восстановления оценивается как $\text{time}\approx \frac{\text{bytes to transfer}}{\text{network bandwidth}}$.
- Перестройка кластера (менеджмент членства):
- Безопасное изменение состава Raft (joint consensus / two-phase membership change) — добавление/удаление реплик без нарушения safety.
- Автоматическая ребалансировка шардов после добавления/удаления нод с контролем пропускной способности (throttling).
- Восстановление после сбоя (пошагово):
1. Обнаружение: heartbeat timeout, мониторинг, alert.
2. Фиксация состояния: лидер продолжает обслуживать записи, пока есть большинство.
3. Решение: если нода восстановилась быстро — просто приёом логов от лидера (catch-up). Если долго — orchestration помечает её как decommissioned и создаёт replacement.
4. Синхронизация replacement: получить snapshot + донаписать лог-entries → ввести в группу через безопасную смену членства.
5. Верификация: проверка целостности, сравнение с помощью Merkle/снимков, завершение ребаланса.
- Защита от корелированных отказов и сетевых разрывов:
- Размещение реплик по зонам/стойкам, настройки timeouts адаптивно.
- Raft предотвращает split-brain через требование большинства; при сетевом разделе меньшая часть теряет лидера и не допускает записей.
- Операционные рекомендации:
- Мониторить lag реплик, latency commit, размер логов и snapshot frequency.
- Ограничивать скорость синхронизации replacement, чтобы избежать перегрузки.
- Регулярные бэкапы и тесты восстановления (DR drills).
- Конфигурировать ACL и шифрование в покое/в пути.
Короткое обоснование выбора: Raft + $N=3$ даёт простую, надёжную модель: потеря одного узла не приводит к потере данных и не нарушает согласованности (majority остаётся), при этом восстановление ноды/замена выполняется безопасно через стандартные механизмы snapshot + log replication и безопасное изменение членства.