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

Перескажу на русском запись о консистентности в БД.

Согласованность (консистентность) в БД - это соблюдение всех ограничений (constraints). Например, в столбце Зарплата не м.б. записей в формате Дата.

Пример с банковскими счетами. Мы храним данные о счетах и общей сумме на всех счетах, обозначим ее T (от TOTAL). В любой момент времени сумма денег на всех счетах должна быть равна T. Но - в результате наших действий может возникнуть несогласованность. Мы кладем деньги на первый счет (скажем, 100 рублей). Далее обновится и T, но между обновлением первого счета и T данные будут несогласованы.

Здесь возникает понятие транзакции. Это набор действий, переводящих данные из одного согласованного состояние в другое (буква С в ACID). Но в процессе выполнения транзакции данные могут (имеют право) быть несогласованы. Соответственно, нам необходимо обновление счета и обновление T объединить в транзакцию.

Но что если в процессе транзакции произойдет сбой? Данные могут остаться в несогласованном состоянии. Избежать этого позволяют транзакционные логи СУБД, о которых тоже есть статья на ML Wiki.

В распределенных БД с согласованностью сложнее. Модели согласованности определяют правила видимости (visibility) и порядка обновлений (order of updates). 

Строгая согласованность. Все реплики видят обновления в одинаковом порядке. Любая операция чтения выдает самые свежие данные, в независимости от того, с какой реплики идет чтение. Необходим некий механизм распространения фиксаций (ommit propagation), например, двухфазная фиксация. Согласно CAP теореме невозможно достичь строгой согласованности одновременно с устойчивостью к разделению сети (partition-tolerance).

Согласованность в конечном счете (eventual consistency). Важен порядок получения обновлений. При  t→∞ все читатели увидят записи. Но обновления не атомарны, как в 

строгой согласованности.

Слабая согласованность. Все реплики увидят обновления. Но нет гарантий порядка пихода обновлений, старое обновление может затереть новое.