Коротко: при сетевом разъединении нужно выбрать, что важнее для приложения — согласованность (C) или доступность (A) — и подобрать стратегию репликации/консенсуса и разрешения конфликтов соответственно. Ниже — конкретные стратегии и примеры компромиссов по типам приложений.
Общие принципы
- CAP: при разрыве сети нельзя одновременно иметь строгую C и A. Выбор зависит от требований приложения.
- Кворумная репликация: параметры чтения/записи $R,W$ и число реплик $N$. Для обеспечения сильной консистентности требуется
$$R+W>N$$ Пример: $N=3$ — типичные варианты: $W=2,R=2$ (баланс), $W=3,R=1$ (сильнее на записи).
- Типы репликации: синхронная (ждать подтверждений — сильная C, повышенная латентность), полусинхронная/кворум, асинхронная (низкая латентность, возможна раздвоенность).
- Протоколы/решения: Raft/Paxos (лидерный консенсус — CP), Spanner (спец. синхронизация времени — внешний консенсус), leaderless (Cassandra, Dynamo — AP с настраиваемым кворумом), CRDT/OT (конвергентность без дедлоков).
Рекомендации по типам приложений
1) Финансы, банковские транзакции, бухгалтерия
- Требование: строгая согласованность, атомарность.
- Стратегия: синхронная репликация через консенсус (Raft/Paxos/Multi-Paxos) или транзакционные глобальные решения (Spanner/CockroachDB).
- Пример конфигурации: кластер Raft с $N=3$ или $N=5$ узлами, требования к записи — подтверждение мажоритета $W=\lceil N/2\rceil$.
- Компромисс: повышенная задержка и потенциальная недоступность при сетевом разделе (CP: при разрыве часть клиентов не сможет писать).
2) Управление запасами (инвентарь) в e‑commerce
- Требование: на некоторые операции — строгая согласованность (резервирование товара), на остальные — eventual.
- Стратегия: гибрид: критичные операции — синхронный кворум по ключу (leader или per-shard consensus), остальные — асинхронная репликация + фоновые корректировки.
- Пример: для шардированной товарной записи $N=3$, использовать $W=2,R=1$ для подтверждения резерва; для аналитики — асинхронно.
- Компромисс: локальные задержки на подтверждение резерва, но высокая пропускная способность для не-критичных запросов.
3) Социальные ленты, логи активности, рекомендательные системы
- Требование: высокая доступность и низкая латентность; возможны временные рассогласования.
- Стратегия: асинхронная репликация или leaderless с eventual consistency (Cassandra, Dynamo), CRDT для некоторых агрегатов.
- Пример: $N=3$, $W=1,R=1$ — максимальное A; возможен фоновой read-repair.
- Компромисс: пользователи могут видеть старые или немотивированные порядки постов; требуются механизмы слияния.
4) Совместное редактирование (реальное время: документы, доски)
- Требование: интерактивность + сходимость.
- Стратегия: CRDT или OT (оперативно трансформируемые операции) с локальными коммитами и фоновой синхронизацией; при необходимости — лидер для сериализации критичных участков.
- Пример: репликация изменений локально и распространение по P2P/серверу; конфликтное слияние за счёт CRDT.
- Компромисс: сложность реализации CRDT/OT, увеличение объёма метаданных, возможные семантические несовпадения, но высокая доступность.
5) IoT и телеметрия
- Требование: высокая доступность на устройствах, толерантность к задержкам, приоритет — сбор данных.
- Стратегия: асинхронная репликация, локальные буферы (hinted handoff), компрессия батчей, eventual consistency в центральном хранилище.
- Компромисс: возможна потеря актуальности данных при рассинхронизации, но минимальная зависимость от сети.
6) Системы очередей/сообщений
- Требование: гарантия доставки (at-least-once или exactly-once), порядок сообщений для некоторых сценариев.
- Стратегия: для порядка — лидер с синхронной репликацией (Kafka — ISR), для масштабируемости — партиционирование и асинхронные реплики.
- Компромисс: ISR (in-sync replicas) повышают надежность, но увеличивают время подтверждения записи; exactly-once требует идемпотентности и дополнительных координаторов.
7) Аналитика/OLAP
- Требование: доступность и скорость загрузки; строгая согласованность не критична.
- Стратегия: асинхронная репликация, снапшоты, ETL в аналитическое хранилище; возможны eventual-consistent индексы.
- Компромисс: аналитика работает на задержанных данных, но нагрузка на OLTP минимальна.
Стратегии разрешения конфликтов
- Last-Write-Wins (LWW) с физическим/логическим временем — простая, может потерять данные.
- Vector clocks — детектируют конфликты, требуют разрешения (автоматическое или ручное).
- CRDT — автоматическая конвергенция без конфликтов для определённых типов данных.
- Application-level merge / compensating transactions — лучший вариант для бизнес-логики, но сложнее.
Операционные механизмы и рекомендации
- Настройка таймаутов и ретраев, идемпотентность операций.
- Мониторинг расколов, метрик согласованности и задержек.
- Поддержка разнородных режимов: degraded mode (только чтения при потере кворума), режимы «read-only» для части кластеров.
- Тестирование partition‑tolerance (chaos testing).
- Документировать SLAs: какие операции теряют A или C при partition.
Краткие примеры компромиссов
- CP (Raft): сильная C, но при разделении часть клиентов теряет возможность писать (низкая A).
- AP (Cassandra, eventual + CRDT): высокая A и низкая латентность, но сложные конфликты и временная рассогласованность.
- Tunable consistency (Cassandra): можно настраивать $R,W$ для каждого запроса — гибридный компромисс.
Итого: для каждого класса приложений выбирайте стратегию по требованию к C/A, используйте кворумы и протоколы, соответствующие этой цели, и реализуйте адекватное разрешение конфликтов (CRDT, vector clocks, app-merge) + операционные практики (таймауты, мониторинг, тесты).