🔼🔽Согласованность данных

Согласованность (consistency) — состояние, когда все пользователи и процессы видят одни и те же данные при чтении
🤩согласованность не равна целостности (integrity)
🤩целостность описывает корректность данных внутри системы (например, наличие внешних ключей, ограничения на значения)

🤩согласованное состояние: после завершения операции или транзакции все узлы системы переходят в один и тот же видимый результат.
Иначе пользователи видят разные версии, что может привести к бизнес-ошибкам.


Виды

⚪️Строгая (strong consistency): после записи данные моментально видны всем
✨пример: традиционные реляционные БД с синхронными транзакциями

⚪️В конечном счёте (eventual): данные со временем сходятся, но на промежутке возможны расхождения (DynamoDB, Cassandra)

⚪️Последовательная (sequential): все операции видятся в одном порядке, но нет гарантии мгновенной видимости

⚪️Каузальная (causal): операции, имеющие причинно-следственную связь, видятся в правильном порядке

⚪️Слабая (weak): система не гарантирует моментальной или даже определённой очередности обновлений

При выборе вида согласованности:
✨учитывать нагрузку, ожидаемые задержки, требования к откатам и репликации
✨можно использовать матрицу реiений с параметрами: задержка, SLA по доступности, бизнес-ущерб при ошибке и тд

Примеры

⏺ Критичные данные (банковские счета, заказы, бронирования) ➡️ strong consistency
⏺Для аналитических / временных данных ➡️ eventual consistency или quorum-based решения


CAP-теорема, ACID, BASE и согласованность

🤩CAP-теорема утверждает: распределённая система может одновременно гарантировать только две из трёх свойств:
- согласованность
- доступность
- устойчивость к разделению
🤩Устойчивость к разделению обязательна для любой распределённой системы, выбор обычно стоит между согласованностью и доступностью.


🤩ACID (Atomicity, Consistency, Isolation, Durability) — свойства традиционных реляционных транзакций
🤩Гарантируют строгую согласованность и корректность данных, но плохо масштабируются


🤩BASE (Basically Available, Soft state, Eventually consistent) — подход, характерный для NoSQL-систем:
🤩BASE-системы жертвуют частью согласованности ради масштабируемости и отказоустойчивости


Методы обеспечения согласованности

✨Репликация

✨Синхронная: запись дожидается подтверждения всех реплик. Высокая надёжность, но медленнее
✨Асинхронная: запись подтверждается после обновления основной реплики, остальные догоняют позже. Быстрее, но риск рассинхронизации

✨Консенсус-протоколы

Алгоритмы, которые позволяют множеству узлов в распределённой системе согласовать единое состояние данных, даже если часть узлов или сеть работает нестабильно

✨пример: алгоритмы Paxos и Raft широко используются внутри распределённых БД и сервисов. Для репликации и выбора лидера, чтобы все копии данных оставались согласованными

✨Конфликт-резолвинг

Подходы к устранению расхождений между копиями данных при eventual consistency

✨ CRDT (Conflict-free Replicated Data Types)

Структуры данных.
Спроектированны так, чтобы изменения, сделанные независимо на разных узлах, могли быть объединены без конфликтов
Позволяет достичь согласованности без централизованного координирующего узла

✨пример: распределённый счётчик, который можно увеличивать на любом узле, а потом безопасно объединять — каждая часть учтётся, независимо от порядка доставки

✨Last-write-wins (LWW)

Стратегия разрешения конфликта, когда сохраняется последнее по времени обновление.
Простая реализация, но возможна потеря промежуточных изменений

✨пример: в системе заметок, если два пользователя одновременно редактируют текст, то сохранится та версия, что была записана позже по времени, даже если другая содержала правки


📎 Материалы

1. Согласованность: что этои почему с ней все так сложно
2. Проблемы согласованности в микросервисах и их решение
3. Согласованность, Репликация и БД по CAP
4. Паттерны для высокой масштабируемости
5. Руководство по Эффективному Взаимодействию

#проектирование

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу