Chernyavsky Dev

Строгая vs Последовательная vs Конечная vs Слабая согласованность

4 min read

В распределённых и параллельных системах очень важно понимать, какой уровень согласованности данных обеспечивается системой. От этого зависят корректность работы, производительность и пользовательский опыт. Различные модели согласованности устанавливают разные гарантии о том, как и когда изменения становятся видимы другим участникам системы. Важно уметь различать эти модели, чтобы правильно выбирать подходящие технологии и архитектурные решения.

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

Строгая (Strong consistency)

Аналогия: банковский счёт в одном отделении

Если ты снял деньги, то все другие видят, что ты их уже снял. Всегда читаешь последнее актуальное значение, независимо от того, где читаешь.

Пример: чат в мессенджере

  • Ты отправил A, потом B, потом C.
  • Каждый участник моментально видит A, затем B, затем C, в тот же момент, как ты их отправил.
  • Без задержек, порядок строго как при отправке.

Типичные случаи использования:

  • Банковские и финансовые системы — требуют, чтобы все клиенты одновременно видели актуальные балансы и операции.
  • Системы бронирования авиабилетов и отелей — важно избежать конфликтов и двойного бронирования.
  • Распределённые базы данных с синхронной репликацией — все узлы обязаны видеть последние данные одновременно, чтобы обеспечить целостность.
  • Критичные бизнес-приложения, где ошибки из-за несогласованности недопустимы.

Примеры систем и баз данных:

  • Zookeeper, Etcd, Spanner (Google), PostgreSQL (синхр. репликация)

Последовательная (Sequential consistency)

Аналогия: очередь в магазине, где все видят одни и те же действия, но с задержкой.

Все видят действия в одном и том же порядке, но не обязательно мгновенно.
Главное — порядок соблюдён: если A увидел изменения X до Y, то B тоже увидит X до Y.

Пример: чат в мессенджере

  • Ты отправил A, потом B, потом C.
  • Все друзья получат A, потом B, потом C.
  • Порядок у всех одинаковый, но возможно с задержкой — кто-то получил A через 10 секунд, кто-то через 20 минут, а кто-то — сразу.

Типичные случаи использования:

  • Многоядерные процессоры и архитектуры (IBM Power, ARM с настройками) — упорядочивают операции памяти для корректного параллелизма.
  • Языки программирования и их модели памяти (например, Java Memory Model) — обеспечивают согласованное упорядочивание изменений между потоками.
  • Распределённые базы данных с консистентными транзакциями, где важен порядок операций, но не требуется мгновенная актуальность.
  • Системы с блокировками и атомарными операциями — для синхронизации и согласования доступа к данным.

Примеры систем и баз данных:

  • Zookeeper, Etcd, Consul (частично)

Конечная (Eventual consistency)

Аналогия: пересылка письма почтой.

Ты отправил письмо, но не знаешь, когда оно дойдёт. Главное — оно в конце концов дойдёт, и все получат одинаковую информацию.

Пример: чат в мессенджере

  • Ты отправил A, потом B, потом C.
  • Один друг получил C, потом A, потом B.
  • Второй — A, C, B.
  • Но через какое-то время у всех будет полный список A, B, C — но не обязательно в том порядке, в котором ты отправил.

Типичные случаи использования:

  • Распределённые NoSQL базы данных и хранилища — где важна высокая доступность и масштабируемость.
  • DNS-системы — обновления распространяются с задержкой, но в итоге все сервера синхронизируются.
  • Мессенджеры с оффлайн-режимом — сообщения доходят не всегда в порядке, но достигают всех в конечном итоге.
  • Облачные хранилища и CDN — данные реплицируются с задержками, обеспечивая доступность в масштабах сети.

Примеры систем и баз данных:

  • DynamoDB, Cassandra, Riak, S3, MongoDB (по умолчанию)

Слабая (Weak consistency)

Аналогия: слухи в деревне.

Ты рассказал кому-то новость — не факт, что другие сразу узнают. Может узнают позже, может нет. Нет гарантий, когда узнают и узнают ли вообще.

Пример: чат в мессенджере

  • Ты отправил A, потом B, потом C.
  • Кто-то получил только А, кто-то B и С, кто-то A и B, а кто-то вообще ничего не получил.
  • Сообщения могут не дойти вовсе, или прийти в любом порядке, без каких-либо обязательств со стороны системы.

Типичные случаи использования:

  • Кэш-системы браузеров и прокси — где не критично, что данные обновляются с задержкой или могут быть устаревшими.
  • Системы мониторинга и телеметрии — данные могут приходить с задержками или пропусками, но не влияют на критичные решения.
  • Протоколы передачи без подтверждения (UDP) — не гарантируют доставку и порядок.
  • P2P-сети и CDN-кэши без строгих TTL — где отсутствуют гарантии доставки и актуальности.

Примеры систем и баз данных:

  • Redis (в режиме кэша), UDP, BitTorrent, CDN без строгих правил TTL

Таблица сравнение типов согласованности

Тип согласованностиГарантирует порядок?Гарантирует актуальность?Когда все синхронизируются?
Строгая (Strong) - все видят последнюю версию мгновенно, как будто база одна✅ Да✅ Да✅ Сразу
Последовательная (Sequential) - изменения видны всем в одном порядке, но не всегда актуальны✅ Да❌ Нет❌ Неизвестно когда
Конечная (Eventual) - все узлы в итоге придут к одному значению, но в разном порядке❌ Нет❌ Нет✅ Со временем
Слабая (Weak) - никаких гарантий ни на порядок, ни на актуальность❌ Нет❌ Нет❌ Может никогда

Graph View