---
aliases: 
tags:
  - зрелость/🌱
date:
  - - 2024-06-04
zero-link:
  - "[[00 Базы Данных]]"
parents:
  - "[[Репликация БД]]"
linked:
---
![800](Pasted%20image%2020240226135429.png)

Клиент сразу пишет во все реплики. До каких-то информация доходит, до каких-то нет. Реплики возвращают результаты, клиент их подсчитывает. Если количество успешных ответов больше, чем заранее определенное число 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
- Нет отката транзакций.
	- Как в таком случае работает обновление при чтении или противодействие энтропии, ведь эти данные становятся новыми.
- Конфликт записей и [Потерянное обновление](Потерянное%20обновление.md).
- Проблемы с линеаризуемостью.