3.2 KiB
3.2 KiB
| aliases | tags | date | zero-link | parents | linked | |||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
Клиент сразу пишет во все реплики. До каких-то информация доходит, до каких-то нет. Ноды возвращают результаты, клиент их подсчитывает. Если количество успешных ответов больше, чем заранее выставленное число 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.
- Векторы версий.
- Tombstone
Проблемы:
- Нестрогий кворум. Возможно чтение старых данных при W+R < N
- Нет отката транзакций.
- Как в таком случае работает обновление при чтении или противодействие энтропии, ведь эти данные становятся новыми.
- Конфликт записей и потерянное обновление
- Проблемы с линеаризуемостью.