|
|
@@ -0,0 +1,18 @@
|
|
|
+# Лекция 2: Согласованность в распределенных системах: теорема CAP и практические паттерны
|
|
|
+
|
|
|
+**Согласованность в распределенных системах определяет гарантии**, которые система дает относительно того, когда операция записи становится видимой для последующих операций чтения. Классическая теорема CAP (Brewer) постулирует, что в условиях сетевого раздела (Partition tolerance) распределенная система может обеспечить только либо **Согласованность (Consistency)**, либо **Доступность (Availability)**, но не оба свойства одновременно. На практике большинство современных систем выбирают вариант **PA/EL** (Availability + Partition Tolerance с отложенной согласованностью), реализуя модель **согласованности в конечном счете (Eventual Consistency)**.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+С инженерной точки зрения, выбор модели согласованности **определяет архитектуру и сложность** системы. Сильная согласованность (как в CP-системах: ZooKeeper, etcd) достигается через консенсус-алгоритмы (Raft, Paxos), блокирующие запись до репликации на кворум узлов, что снижает доступность при сетевых проблемах. В основе **Eventual Consistency** лежат асинхронная репликация и разрешение конфликтов. Системы вроде DynamoDB или Cassandra используют механизмы вроде Vector Clocks, Last Write Wins (LWW) или пользовательских функций слияния (CRDTs — Conflict-free Replicated Data Types) для согласования расходящихся версий данных.
|
|
|
+
|
|
|
+### Таблица 2. Паттерны обеспечения согласованности в различных сценариях
|
|
|
+| Паттерн | Пример использования | Механизм | Компромисс |
|
|
|
+|---------|---------------------|----------|------------|
|
|
|
+| Кворумная запись/чтение (Read/Write Quorum) | DynamoDB, Cassandra | Запись считается успешной при подтверждении от `W` узлов, чтение запрашивает `R` узлов, где `R + W > N`. Гарантирует актуальность данных. | Увеличивает latency, так как требует ответа от нескольких узлов. |
|
|
|
+| Лидер-фолловер с синхронной репликацией | PostgreSQL с синхронной репликой | Запись фиксируется только после подтверждения от синхронной реплики. Обеспечивает сильную согласованность и надежность. | Доступность теряется, если реплика недоступна; производительность записи падает. |
|
|
|
+| Компенсирующие транзакции (Saga Pattern) | Микросервисная архитектура | Длинная бизнес-транзакция разбивается на этапы, каждый со своей локальной транзакцией. В случае сбоя запускаются компенсирующие транзакции для отката. | Сложность реализации, система в целом становится лишь в конечном счете согласованной. |
|
|
|
+
|
|
|
+Практический выбор всегда является **компромиссом, основанным на бизнес-требованиях**. Нужна ли абсолютная консистентность для финансового баланса (да) или допустима задержка в несколько секунд для количества лайков (нет). Понимание этого **позволяет** **выбирать подходящие инструменты** и проектировать корректные протоколы взаимодействия между сервисами.
|
|
|
+
|
|
|
+Таким образом, управление согласованностью — это **критический навык для архитектора распределенных систем**, требующий глубокого понимания не только теоретических пределов (теорема CAP, FLP), но и практических механизмов их обхода в реальных, неидеальных условиях.
|
