Модели согласованности

Согласованность описывает, какие значения и в каком порядке видят читатели при конкурентных изменениях. Правильный выбор модели — это баланс между строгостью инвариантов, латентностью, доступностью и стоимостью (PACELC). Ниже — практический справочник по моделям и их применению.

1) «Строгие» модели

Linearizable (линейризуемость, Strong)

Поведение как будто все операции выполнялись мгновенно в некотором едином порядке, уважающем реальное время.
Плюсы: простая ментальная модель, безопасна для денег и уникальностей.
Минусы: кворумы/лидер → рост p95/p99, особенно межрегионально.
Юзкейсы: балансы, инвентарь с жесткими лимитами, уникальные имена/ключи.

Sequential consistency

Все потоки видят один и тот же порядок операций, но не обязателен реал-тайм порядок. Чуть слабее linearizable, редко экспонируется напрямую в продуктах.

Serializable (транзакционная сериализуемость)

Эквивалентно некоторому последовательному порядку транзакций (а не отдельных операций).
Плюсы: корректность сложных инвариантов на уровне запросов/таблиц.
Минусы: дороже (блокировки/версионирование/валидация конфликтов).
Юзкейсы: сложные финоперации, консистентные пересчеты, инвентарь.

Snapshot Isolation (SI)

Каждая транзакция читает неизменяемый снимок во времени; записи конфликтуют по «одинаковым строкам», но возможен write skew.
Плюсы: быстрые чтения без блокировок, стабильные отчеты.
Минусы: не сериализуемо, ловушка write skew (пример: дежурные врачи).
Юзкейсы: аналитика, отчеты, большинство CRUD без жестких инвариантов.

2) Per-session и причинные гарантии

Read-Your-Writes (RYW)

Клиент после своей записи всегда видит ее в последующих чтениях.
Плюсы: хороший UX (форма → подтверждение).
Минусы: локальная гарантия, не глобальная.

Monotonic Reads / Writes

Чтения не «откатываются» назад; записи одного клиента применяются в том же порядке, что и отправлялись.

Causal Consistency (причинная)

Если операция зависит от другой (A → B), все видят A перед B.
Плюсы: интуитивно для соц-фидов, комментариев.
Минусы: сложнее маршрутизация и метки причинности (векторные часы).
Юзкейсы: коммуникации, совместное редактирование, ленты событий.

3) Слабые и гибридные модели

Bounded Staleness

Чтения могут отставать не более Δt или N версий.
Плюсы: предсказуемый UX, хороший компромисс межрегионально.
Минусы: не защищает от конфликтов записи.

Eventual Consistency

Со временем все копии сходятся; порядок и задержка не гарантированы.
Плюсы: минимальная латентность/стоимость, высокая доступность (AP).
Минусы: нужен явный merge (CRDT/правила домена).
Юзкейсы: кэши, фиды, метрики, лайки, нен critical справочники.

4) Типовые аномалии и что они значат

Dirty Read: чтение незакоммиченных данных.
Non-repeatable Read: одно и то же чтение внутри транзакции дает разные значения.
Phantom: при повторном запросе появляется/исчезает строка, подходящая под предикат.
Write Skew (при SI): две транзакции читают пересекающийся инвариант и записывают разные строки, нарушая условие «в сумме должно быть ≥ 1».
Lost Update: запись «затирает» изменения конкурента.

5) Кворумы и уровни чтения/записи

Многие хранилища позволяют задавать уровни `R`/`W` (число реплик для чтения/записи).

Кворум (R+W > N) дает «пересечение» и сильные гарантии чтений последней записи.
W=1, R=1 → низкая задержка, но возможны старые данные.
Тюнинг: критичным операциям — высокий `W` (или лидер), остальным — низкий `R` для скорости.
Read-repair / Hinted handoff помогают добирать согласованность в фоне.

6) Часы и порядок: как мы «понимаем» причинность

Lamport clocks: частичный порядок событий.
Vector clocks: фиксируют причинность, позволяют детектить конфликты.
Hybrid/TrueTime-подходы: ограничивают разброс часов в кластере для упорядочивания транзакций и bound-staleness.
Версионирование: `version/ts + actor` для merge; в CRDT — замкнутые полугруппы (коммутативность/идемпотентность).

7) CRDT и доменный merge

CRDT (конвергентные/реплицируемые типы данных) гарантируют схождение без координации: G-Counter, OR-Set, LWW-Register, Map, текстовые OT/WOOT-варианты.
Когда полезно: лайки, множества тегов, корзины, документы.
Ограничения: придумать корректную семантику «слияния» для конкретной доменной сущности.

8) Связь с CAP/PACELC

Строгие модели (Linearizable/Serializable) в мульти-регионе → CP с ростом латентности (PACELC: выбираем C и платим L).
Слабые/гибридные модели → AP и/или низкая L, но нужен merge/конфликт-резолв.
Гибрид: CP-ядро для инвариантов + AP-проекции/кэши для чтений.

9) Выбор модели: чек-лист

1. Инварианты: что нельзя нарушать? (уникальность, баланс, лимиты).
2. Региональность: где выполняются записи/чтения? (локально/глобально).
3. SLO по латентности: p95/p99 для критичных путей?
4. Цена координации: готовы платить межрегиональными кворумами?
5. Конфликты: есть детерминированный merge или нужен координатор?
6. UX-ожидания: RYW/monotonic/causal для клиента важны?
7. Наблюдаемость: чем меряете лаг/конфликтность/степень устаревания?
8. Фолбэки: что происходит при разделении сети (P)? read-only/локальная запись/очереди?

10) Быстрые рецепты

Платеж/баланс: Linearizable/Serializable, лидер + кворум, короткие таймауты; чтения RYW.
Профили/фид: Causal/Bounded staleness + кэш; CRDT для лайков/счетчиков; RYW для автора.
Поиск/аналитика: SI/Read Committed, асинхронные проекции, eventual для индексов.
Глобальный SaaS: Geo-partitioning; «домашние записи» — CP, отчеты/каталоги — AP.
Совместное редактирование: причинная/eventual + CRDT/OT; сохранение «истории».

11) Наблюдаемость согласованности

Lag метрики: `replication_lag`, `staleness_age_ms` (p50/p95/p99).
Конфликтность: доля конфликтов, среднее время разрешения.
Кворумы: успешность `R/W` кворумов, таймауты межрегиональных путей.
Клиентские гарантии: RYW/monotonic — трейс-метки по сессиям.

12) Типичные ошибки

Требовать Strong «везде» без бизнес-основания → взрыв латентности и стоимости.
Dual-write в разные регионы без саг/CRDT → фантомы и потеря инвариантов.
Игнорировать RYW/монoтоничность в UX → «пропажа» только что отправленных данных.
Не отслеживать устаревание кэшей/проекций → «вечные» расхождения.
Непродуманный merge → неожиданные потери/дубли значений.

13) Мини-эталон архитектуры

Write-core (CP): лидер, кворумные записи, SLO и таймауты, журналы.
Read-plane (AP): материализованные представления, TTL-кэши, read-repair.
Клиент: sticky-session/сессионные гарантии (RYW/monotonic), метки версии.
Конфликт-движок: CRDT/доменные правила, очередь ручного урегулирования.
Мониторинг: лаги, конфликты, доли устаревших чтений.

Заключение

Модель согласованности — это инженерный контракт между данными, задержкой и доступностью. Начинайте с инвариантов и SLO, выбирайте строго там, где нужно, и слабее там, где можно, не забывая про клиентские гарантии, кворумы, часы и наблюдаемость. Грамотная комбинация моделей дает масштаб, предсказуемость и устойчивость — без жертвования бизнес-правдой и пользовательским доверием.