Кратко — определение, сравнение по поведению при сетевых разделениях и практические решения/примеры.
1) Что такое
- Strong consistency (линеаризуемость/сериализуемость): любые прочитанные данные выглядят как будто операции выполняются последовательно в каком‑то порядке; после подтверждённой записи все последующие чтения увидят эту запись. При сетевом разбиении обычно жертвует доступностью (CP в терминах CAP).
- Eventual consistency: при отсутствии новых обновлений все реплики со временем сойдутся к одному значению; отдельные чтения могут видеть устаревшие данные, но система остаётся доступной во время разделений (AP).
2) Поведение при сетевых разделениях (ключевые различия)
- Strong: чтобы сохранить согласованность требуется глобальный консенсус/кворумы — если узлы не могут договориться, часть запросов отклоняется/блокируется (низкая доступность в разбиении). Частые блокировки, больше задержка.
- Eventual: разрешает операции на разных частях сети независимо; доступность высокая, но возникают конфликты и задержка с «сходимостью» данных.
3) Технические механизмы (решения)
- Для strong consistency:
- Алгоритмы консенсуса: Paxos, Raft — применяются для выборов лидера и репликации лога; дают линейаризуемые записи при активном кворуме.
- Распределённые транзакции/2PC (two‑phase commit) и распределённые блокировки → обеспечивают сериализуемость, но подвержены блокировкам при разделениях.
- Глобальные часы / TrueTime (Google Spanner) → внешняя согласованность при геораспределённой записи.
- Примеры систем: Google Spanner, CockroachDB (Raft на диапазонах), Apache Zookeeper (ZAB), etcd.
- Правило кворума: большинство: требуется согласие > $\frac{N}{2}$ узлов для принятия решения.
- Для eventual consistency:
- Dynamo‑style репликация: разрешённые записи на любых репликах, конфликтное разрешение (vector clocks, LWW).
- Анти‑энтропия (gossip), hinted handoff, мерджи при повторной синхронизации.
- CRDT (конфликтно‑разрешающие типы данных) для детерминированного слияния без координации.
- Tunable consistency (Cassandra/DynamoDB): можно задать $R$ и $W$ — число реплик для чтения/записи; при выборе $R+W>N$ достигается гарантия, близкая к сильной для обычных отказов.
- Примеры систем: Amazon Dynamo / DynamoDB (тюнинг), Apache Cassandra, Riak, CouchDB (replication + MVCC), many key‑value stores.
4) Практические рекомендации
- Нужна строгая корректность (финансовые операции, лидерство) → strong (консенсус, транзакции, возможно сниженная доступность в разбиениях).
- Нужна высокая доступность/низкая латентность для большого числа геораспределённых клиентов (социальные ленты, кэш, некоторые ключ‑значение) → eventual + CRDT/разрешение конфликтов.
- Гибрид: использовать тюнинговые кворумы ($R+W>N$) или разделять данные по требованию: критичные объекты — strong, менее критичные — eventual.
5) Короткие формулы/правила
- Кворум для консенсуса: большинство $>\frac{N}{2}$.
- Quorum‑параметры Dynamo/Cassandra: гарантия обновления прочтения при отсутствии сбоев если $R+W>N$.
Вывод: выбор — компромисс между согласованностью и доступностью в разделении. Strong требует координации (консенсус, жертва доступностью при разделениях); eventual даёт доступность и масштабируемость, но требует механизмов разрешения конфликтов (vector clocks, CRDT, анти‑энтропия).