Распределённые системы
Кворумы: чтение конфигов и кода
Суть Читайте реальные конфигурации уровней согласованности и проверку пересечения кворума, предсказывайте, гарантирует ли каждая последнюю запись, и выбирайте самый рычажный фикс.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеБаги кворума живут в строках уровня согласованности вашего кода доступа к данным, а не в самой базе. Прочитайте каждый конфиг и сниппет, сделайте арифметику R + W против N и выберите фикс, который сделал бы senior-инженер первым.
Цель
Отработайте цикл, который вы запускаете, когда прилетает тикет про устаревшее чтение: найдите R и W в коде, проверьте, действительно ли R + W > N для replication factor этого keyspace, и потянитесь к фиксу, который восстанавливает пересечение, а не прячет его.
Сниппет 1 — раздельная согласованность чтения и записи
# keyspace создан WITH replication = { 'class': 'SimpleStrategy', 'replication_factor': 3 }
session.execute(
SimpleStatement(
"UPDATE accounts SET payout = %s WHERE id = %s",
consistency_level=ConsistencyLevel.QUORUM, # W = 2 при RF=3
),
(new_payout, account_id),
)
balance = session.execute(
SimpleStatement(
"SELECT payout FROM accounts WHERE id = %s",
consistency_level=ConsistencyLevel.ONE, # R = 1
),
(account_id,),
).one() Викторина
Completed
Запись — QUORUM (W=2), а чтение — ONE (R=1) при RF=3. Гарантирует ли это, что чтение увидит последний payout, и в чём фикс?
Heads-up QUORUM-запись на 2 из 3, но R=1 может прочитать оставшуюся 1, которая отстала. Нужно R + W > N (принудительное пересечение), а не просто мажоритарная запись. 1 + 2 = 3 не удовлетворяет > 3.
Heads-up W=3 при R=1 даёт сумму 4 > 3 и сработает, но запись в ALL проваливает каждую запись при одном упавшем узле — ужасная доступность для платёжной записи. Поднятие ЧТЕНИЯ до QUORUM сохраняет переживание отказа одного узла на обоих путях.
Heads-up Координатор маршрутизирует чтение на реплики; он не обязательно реплика этого ключа и не обязан держать последнюю версию. Пересечение должно обеспечиваться через R + W > N.
Сниппет 2 — хелпер проверки пересечения
def guarantees_latest_read(n: int, r: int, w: int) -> bool:
# True тогда и только тогда, когда чтение гарантированно видит последнюю запись
return r + w > n
# вызвано для плана нового keyspace, RF = 4
print(guarantees_latest_read(n=4, r=2, w=2)) # что напечатает и безопасно ли это? Викторина
Completed
При N=4 с R=2, W=2 что напечатает guarantees_latest_read и верный ли это ответ?
Heads-up 2 не большинство от 4 — строгое большинство 4 это 3. И хелпер использует строгое >, так что 2 + 2 = 4 даёт False. Кластеры с чётным N — классическая ловушка: 'половинное' чтение и 'половинная' запись могут не пересечься.
Heads-up Строгое > здесь точно верно. При R + W = N множества могут быть идеально непересекающимися (например, узлы {1,2} пишут, {3,4} читают при N=4), так что >= ложно сообщил бы о безопасности. Пересечению по принципу Дирихле нужно R + W > N.
Heads-up Больший RF сам по себе не даёт пересечения; его даёт выбор R/W. R=2,W=2 при N=4 даёт сумму 4, проваливает тест > N и допускает устаревшие чтения независимо от числа реплик.
Сниппет 3 — путь записи sloppy quorum
def write_quorum(coordinator, key, value, n=3, w=2):
home = coordinator.preference_list(key, n) # N назначенных реплик
live = [node for node in home if node.is_reachable()]
acks = [node.store(key, value) for node in live]
if len(acks) >= w:
return "OK (strict quorum)"
# недостаточно назначенных реплик доступно -> sloppy quorum
for sub in coordinator.next_healthy_ring_nodes():
acks.append(sub.store_hint(key, value, intended_owner=...))
if len(acks) >= w:
return "OK (sloppy quorum)" # подтверждено, но где?
return "FAIL" Викторина
Completed
Когда это возвращает 'OK (sloppy quorum)' во время partition, каково следствие для согласованности конкурентного строгого QUORUM-чтения с домашних реплик?
Heads-up store_hint пишет на УЗЛЫ-ЗАМЕСТИТЕЛИ (next_healthy_ring_nodes), а не на назначенные реплики. Чтение домашнего preference list может полностью пропустить hint, пока hinted handoff не завершится.
Heads-up Hint'ы не блокируют и не проваливают чтения домашних реплик; те просто отдают свою (более старую) версию. Чтение успешно и возвращает устаревшие данные — тихий режим сбоя.
Heads-up Нет гарантии порядка между handoff и гонящимся чтением. В окне partition чтение может прийти раньше handoff — это ровно тот шов устаревшего чтения, который открывает sloppy quorum.
Сниппет 4 — флаг чтения DynamoDB
# DynamoDB, репликация управляется; согласованность чтения вы выбираете на запрос
resp = table.get_item(
Key={"id": account_id},
ConsistentRead=False, # по умолчанию: eventually consistent
) Викторина
Completed
Чтение баланса использует ConsistentRead=False. Что даёт переключение на True и чего это стоит — в терминах кворума?
Heads-up Он меняет наблюдаемые данные: False может вернуть значение с реплики, ещё не получившей недавнюю запись (устаревшее), а True гарантированно отражает все предыдущие подтверждённые записи. И стоит ~2x RCU.
Heads-up ConsistentRead — флаг ЧТЕНИЯ и вовсе не меняет durability записи. Он лишь управляет тем, гарантированно ли чтение видит последнюю зафиксированную запись.
Heads-up Оно стоит примерно вдвое больше capacity на чтение и добавляет латентность, поэтому его держат для чтений, которые не должны быть устаревшими (балансы, проверки идемпотентности), а loss-tolerant чтения оставляют eventually-consistent — это компромисс tunable consistency.
Итог
Любой баг кворума читается одинаково: найдите R и W в строках уровня согласованности, найдите N из replication factor keyspace и проверьте R + W > N со СТРОГИМ неравенством — R=1-чтения за QUORUM-записями и любой чётный сплит вроде R=2,W=2 при N=4 — классические ловушки, дающие в сумме N и тихо допускающие устаревшие чтения. Фикс, восстанавливающий пересечение (обычно поднятие уровня ЧТЕНИЯ), лучше фиксов, которые его прячут. Sloppy quorum подтверждает через узлы-заместители с hint вне множества чтения, поэтому его ‘OK’ приостанавливает пересечение во время partition; а управляемые хранилища выставляют ту же ручку как ConsistentRead, где strong-чтения стоят примерно 2x capacity за гарантию.