Кеширование
Dogpile: тест с множественным выбором
Суть Синтез юнита про dogpile в формате выбора — коллизия в момент истечения, коалесинг single-flight, distributed lock с TTL и продлением lease, и почему джиттер не спасает один горячий ключ.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь прямо в инциденте, когда один горячий ключ кладёт origin — не определение для заучивания, а компромисс на блокировке, lease и окне пересчёта.
Цель
Убедись, что связываешь коллизию в момент истечения, коалесинг single-flight, distributed-блокировку с TTL и продлением lease, и раннее вероятностное истечение — синтез, к которому вёл урок.
Викторина
Completed
Один горячий ключ (пересчёт 200ms) кладёт БД каждый раз при истечении TTL под ~5000 req/s. Какой фикс наиболее прямо схлопывает стадо, и какая деталь делает его безопасным?
Heads-up Наоборот. Короче TTL — ключ истекает чаще, и dogpile срабатывает чаще. TTL управляет устареванием, а не коллизией параллелизма в момент истечения.
Heads-up Джиттер разносит пачку ключей, закэшированных вместе. Здесь ровно один горячий ключ — значит ровно один момент истечения и одно стадо; рандомизация момента не уменьшает стадо, которое на нём собирается.
Heads-up Это просто переносит развал на саму БД — 5000 одновременных 200ms-агрегаций. Рычаг — схлопнуть N пересчётов в один, а не выделять ресурсы под N.
Викторина
Completed
Локальный single-flight (мьютекс в процессе) срезал стадо, но БД всё равно видит ~20 одновременных пересчётов на истечение по всему флоту. Почему и что закрывает разрыв?
Heads-up Утечка росла бы безгранично; ~20 точно соответствует числу инстансов. Это покейный коалесинг на процесс, а не баг — граница тут процесс, а не дефект.
Heads-up Тюнинг таймаута влияет на восстановление из дедлока, а не на разлёт по флоту. Даже идеальная локальная блокировка не видит остальные 19 инстансов; нужен общий стор блокировок.
Heads-up 20 — это число инстансов, а не лимит Redis. Проблема в том, что каждый процесс координируется только сам с собой, пока не введён межпроцессный lock.
Викторина
Completed
Ты добавил distributed-блокировку пересчёта, но пропустил TTL блокировки (без истечения). Какой сбой senior-уровня?
Heads-up Round-trip добавляет миллисекунды, но это не режим отказа отсутствующего TTL. Опасность — мёртвый держатель, который не освобождает блокировку и блокирует всех читателей.
Heads-up Паттерн lock-and-wait отдаёт свежее значение после записи. Устаревание — это компромисс stale-while-revalidate, а не следствие отсутствующего TTL блокировки.
Heads-up TTL кэша и TTL блокировки — независимые таймеры. Пропуск TTL блокировки не отключает TTL кэша — он лишь убирает аварийный выход из дедлока.
Викторина
Completed
Пересчёт обычно занимает 2s, но иногда 25s. Ты ставишь TTL distributed-блокировки в 5s. Что идёт не так и каков принцип?
Heads-up Хвост — это и есть вся проблема. TTL под медиану позволяет p99-пересчёту потерять блокировку в полёте, а это ровно тот момент, когда повторное открытие dogpile больнее всего.
Heads-up 5s длиннее типичных 2s, так что обычный случай корректно освобождается по завершении. Дефект всплывает только на 25s-хвосте, где TTL срабатывает до окончания работы.
Heads-up Короткий TTL не блокирует захват; он вызывает преждевременное освобождение. Риск — дублирующие пересчёты после истечения, а не невозможность взять блокировку.
Викторина
Completed
Вместо угадывания TTL блокировки держатель продлевает короткий lease (heartbeat, который продлевает блокировку каждую секунду, пока работает). Что это даёт и какой новый сбой надо обработать?
Heads-up Продление дополняет TTL, а не заменяет его. Именно короткий TTL освобождает блокировку, когда упавший держатель перестаёт продлевать — без него мёртвый держатель всё равно дедлочит всех.
Heads-up Пауза или partition могут заставить держателя думать, что он владеет истёкшим lease, пока другой воркер его уже взял. Нужны fencing-токены или check-and-set запись; одно продление не даёт exactly-once.
Heads-up Heartbeat'ы лишь продлевают блокировку; пересчёт всё равно выполняется один раз целиком. Lease меняет, кто может писать, а не стоимость работы.
Викторина
Completed
Коллега утверждает, что блокировка всегда неверный инструмент, потому что сериализует читателей, и хочет везде раннее вероятностное истечение (XFetch). Когда какой из них на самом деле уместен?
Heads-up XFetch добавляет немного лишнего пересчёта и требует хранить delta и тюнить beta; он блещет на одном горячем ключе, но не универсальная замена. Блокировка с отдачей stale при ожидании уместнее, когда корректность требует одной скоординированной записи.
Heads-up XFetch доказанно почти оптимален (beta=1) именно потому, что каждый читатель бросает кости независимо, так что один обновляет рано и в одиночку до стада. Он намеренно вероятностный, а не случайно ненадёжный.
Heads-up Они бьют в разные точки: блокировка координирует окно промаха, XFetch не даёт истечению совпасть с пиком нагрузки. Выбор зависит от толерантности к stale, числа инстансов и стоимости пересчёта — а не от удобства библиотеки.
Итог
Сквозная линия — одно решение: dogpile это коллизия в момент истечения одного горячего ключа, и каждый фикс бьёт в свою точку этого окна. Single-flight схлопывает N одновременных промахов в один пересчёт — но локальный мьютекс коалесит лишь на процесс, distributed lock нуждается в TTL длиннее худшего пересчёта (или в продлеваемом lease), чтобы упавший держатель не задедлочил всех, а lease всё ещё требует фенсинга против приостановленного держателя. XFetch растворяет коллизию, пересчитывая рано и в одиночку до того, как ключ вообще истечёт под нагрузкой. Джиттер разносит пачку ключей и ничего не делает для одного горячего. Большинство постмортемов про dogpile — про дедлок, сериализацию или двойную запись фикса, а не про исходный промах.