Клиент сразу пишет во все реплики. До каких-то информация доходит, до каких-то нет. Реплики возвращают результаты, клиент их подсчитывает. Если количество успешных ответов больше, чем заранее определенное число W, то мы считаем эту запись успешной. ==Если их меньше, но не 0, отката транзакции не будет.==
Читаем мы также со всех реплик разом, но удастся прочитать может только с нескольких. В таком случае у нас есть число R, которое означает, какое минимальное количество реплик нам должно ответить, чтобы мы считали операцию чтения успешной.
Формула расчета кворума: W + R > number of replics
- W - в каком количестве реплик должна примениться запись, чтобы мы считали ее успешной
- R - со скольки реплик мы должны прочитать значение ключа, чтобы считать, что чтение прошло успешным
Такая репликация есть в:
- DynamoDB
- Cassandra
- Scylla (Переписанная на C++ Cassandra)
- Riak
- Voldemort
**Поддержание консистентности:**
- Анти-энтропия. Реплики переодически ходят друг к другу и синхронизируются.
- Противодействие энтропии. Внешний клиент опрашивает все ноды, находит устаревшие данные и обновляет их.
- Обновление при чтении (Set on read). Берем последнюю версию после чтения и отправляем в реплики с устаревшими данными.
- Last write wins. Кто последний записал, те данные и верные.
- [Happens before](Happens%20before.md).
- Векторы версий.
- [Tombstone](Tombstone.md)
**Проблемы:**
- [Нестрогий кворум](Нестрогий%20кворум.md). Возможно чтение старых данных при W+R <N
- Нет отката транзакций.
- Как в таком случае работает обновление при чтении или противодействие энтропии, ведь эти данные становятся новыми.
