Строгая согласованность

Строгая согласованность (англ. strong consistency) — одна из моделей согласованности данных в распределённых системах и системах управления базами данных (СУБД), при которой любая операция чтения возвращает результат последней завершённой операции записи, причём этот результат гарантированно видим всем последующим операциям чтения во всех узлах системы. Строгая согласованность обеспечивает единое, глобально упорядоченное состояние данных, что делает систему логически неотличимой от однопроцессорной системы с общей памятью.

Определение и ключевые свойства

В контексте распределённых вычислений строгая согласованность предполагает выполнение следующих условий:

• Линеаризуемость (англ. linearizability): все операции (чтения и записи) выглядят так, как будто они выполняются в некотором едином, атомарном порядке, который соответствует реальному времени их выполнения. Если операция A завершилась до начала операции B, то в глобальном порядке A должна предшествовать B.
• Свежесть данных: после успешного выполнения операции записи любая последующая операция чтения (независимо от того, на каком узле системы она выполняется) возвращает именно это записанное значение или значение более поздней записи.
• Атомарность с точки зрения клиента: транзакция, изменяющая данные, либо полностью применяется ко всем репликам, либо не применяется вовсе. Промежуточные состояния не видны другим транзакциям.

Строгая согласованность является самой сильной моделью согласованности в спектре от слабой до строгой. Она противопоставляется согласованности в конечном счёте (англ. eventual consistency), где данные могут временно расходиться на разных узлах, но со временем приходят к единому состоянию.

История и происхождение

Понятие строгой согласованности возникло в контексте развития распределённых систем и теории баз данных. В 1979 году Лесли Лэмпорт ввёл понятие линеаризуемости как формального критерия для оценки корректности распределённых алгоритмов. В 1980-х годах, с развитием реляционных СУБД, требования к согласованности были формализованы в рамках ACID-транзакций (атомарность, согласованность, изоляция, долговечность). В частности, свойство изоляции (I в ACID) в своей строжайшей форме — сериализуемость — тесно связано со строгой согласованностью.

С ростом популярности NoSQL-систем и распределённых хранилищ (например, Apache Cassandra, Amazon DynamoDB) в 2000-х годах возникла необходимость в классификации моделей согласованности. Теорема CAP (Брюэр, 2000) показала, что в распределённой системе невозможно одновременно обеспечить строгую согласованность, доступность и устойчивость к разделению сети. Это привело к тому, что многие системы пожертвовали строгой согласованностью в пользу доступности и производительности, используя более слабые модели.

Реализация и механизмы

Для обеспечения строгой согласованности в распределённых системах применяются следующие механизмы:

• Распределённые блокировки (диспетчеры блокировок): система блокирует все реплики данных на время записи, чтобы ни один другой процесс не мог начать запись или чтение до завершения текущей.
• Двухфазный коммит (2PC): протокол, гарантирующий, что транзакция либо применяется на всех узлах, либо откатывается на всех. Однако 2PC чувствителен к сбоям координатора.
• Протоколы консенсуса: например, Paxos, Raft, Zab. Они обеспечивают согласованное принятие решений в распределённой системе даже при сбоях узлов. Эти протоколы используются в таких системах, как Google Spanner, Apache ZooKeeper, etcd.
• Синхронная репликация: запись считается завершённой только после того, как подтверждение получено от всех (или от кворума) реплик. Это гарантирует, что данные не будут потеряны при сбое, но увеличивает задержку.

Преимущества и недостатки

Преимущества

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

Недостатки

• Снижение доступности (availability): согласно теореме CAP, при разделении сети система вынуждена выбирать между строгой согласованностью и доступностью. Если доступность приоритетнее, система может стать недоступной для записи или чтения до восстановления связи.
• Высокая задержка (latency): синхронная репликация и протоколы консенсуса требуют обмена сообщениями между узлами, что увеличивает время ответа. В глобально распределённых системах (например, между континентами) задержка может достигать сотен миллисекунд.
• Сложность масштабирования: горизонтальное масштабирование (добавление новых узлов) при строгой согласованности требует координации и может приводить к узким местам.

Применение

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

• Финансовые системы: банковские транзакции, биржевые торги, системы расчётов. Ошибка в согласованности может привести к финансовым потерям.
• Системы управления базами данных (СУБД): традиционные реляционные СУБД (например, PostgreSQL, Oracle, Microsoft SQL Server) по умолчанию обеспечивают строгую согласованность в рамках одной транзакции.
• Системы координации: Apache ZooKeeper, etcd, Consul — используются для управления конфигурациями, обнаружения сервисов и распределённых блокировок. Они требуют строгой согласованности для корректной работы.
• Системы управления запасами и бронирования: авиабилеты, гостиницы, товары на складе — чтобы избежать двойных продаж.
• Google Spanner: глобально распределённая база данных, которая обеспечивает строгую согласованность с помощью синхронизации времени (TrueTime API) и протокола Paxos.

Критика и альтернативы

Строгая согласованность подвергается критике за свою неэффективность в высоконагруженных и географически распределённых системах. Основные аргументы:

• Теорема CAP: в условиях реальных сетей с возможными разделениями (сбоями) строгая согласованность неизбежно снижает доступность. Для многих веб-сервисов (социальные сети, ленты новостей, аналитика) доступность важнее абсолютной актуальности.
• Производительность: синхронные механизмы замедляют систему. В системах с миллионами запросов в секунду это может быть неприемлемо.
• Сложность реализации: протоколы консенсуса (Paxos, Raft) сложны в реализации и отладке.

Альтернативой являются более слабые модели согласованности:

• Согласованность в конечном счёте (eventual consistency): данные со временем становятся согласованными, но временно могут быть устаревшими. Используется в Cassandra, DynamoDB, Riak.
• Причинная согласованность (causal consistency): гарантирует, что операции, связанные причинно-следственной связью, видны в правильном порядке. Компромисс между строгой и конечной.
• Согласованность чтения после записи (read-your-writes consistency): гарантирует, что пользователь видит свои собственные изменения, но не обязательно изменения других пользователей.

См. также

• Модель согласованности
• ACID
• Теорема CAP
• Линеаризуемость
• Распределённые вычисления

Источники

• Lamport, L. (1979). «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs». IEEE Transactions on Computers.
• Brewer, E. A. (2000). «Towards Robust Distributed Systems» (Keynote at PODC 2000).
• Gilbert, S., & Lynch, N. (2002). «Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services». ACM SIGACT News.
• Vogels, W. (2009). «Eventually Consistent». Communications of the ACM.
• Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly Media.