Лок и single-flight: ограничение параллельных rebuild

На границе TTL 100 000 запросов бьют во флот из 50 нод. Каждая нода запускает in-process single-flight. Сколько запросов к БД происходит? Не 100 000 — но и не 1. Ответ показывает ровно то, где каждый слой митигации помогает, а где нет.

Митигация 1: распределённый лок с SETNX

Простейшая cross-node митигация: перед запуском rebuild захватить лок. Redis-примитив:

SET lock:key uuid EX 30 NX

• NX — установить, только если ключ не существует (set-if-not-exists).
• EX 30 — авто-истечение через 30 с (страховка от упавших rebuilder-ов).
• uuid — уникальный токен захватывающего процесса (используется для fencing, рассматривается в старшем уроке).

Что происходит на истечении:

1. Запрос-1 приходит. Делает SET lock:homepage:v1 uuid-A EX 30 NX → успех. Запускает rebuild.
2. Запросы 2–N приходят. Делают тот же SET → провал (NX). Видят, что лок занят.
3. Вариант А: каждый ожидающий перепроверяет кеш через короткое ожидание (50–200 мс). К тому моменту rebuild может завершиться.
4. Вариант Б: каждый ожидающий немедленно возвращает fallback (stale-значение, дефолт-страницу, пустой 204).
5. Запрос-1 завершает rebuild. Пишет новое значение. Удаляет лок.

EX=30 — не TTL кеша, а страховка. Если rebuilder падает на шаге 1 без удаления лока, лок авто-истекает через 30 с. EX должен быть больше rebuild p99, но достаточно коротким, чтобы падение не глушило трафик надолго. Типичная цель: 3× среднее время rebuild.

Митигация 2: in-process single-flight

Распределённые локи координируют через флот; single-flight координирует внутри одного процесса. Никакого Redis, никакого сетевого round-trip — только in-process map.

Паттерн:

type SingleFlight struct { mu sync.Mutex; inflight map[string]*call }

1. Запрос приходит; cache miss.
2. Проверить in-process map по ключу. Если Promise / call уже существует → подписаться на него, ждать resolve, вернуть общий результат.
3. Если нет записи → создать новую (Promise), запустить rebuild, добавить в map.
4. Когда rebuild завершается → resolve Promise, удалить из map. Все подписчики получают результат одновременно.

Стандартная библиотека Go поставляет это как singleflight.Group.Do. Эквиваленты Node.js: p-memoize или ручной паттерн Map<key, Promise>.

Стоимость: O(1) lookup в памяти процесса. Без сети. Без acquire лока.

Область действия: только per-process. Флот из 50 нод имеет 50 независимых in-process map. На границе TTL с 100 000 параллельными запросами, равномерно распределёнными, single-flight в одиночку даёт 50 запросов к БД (1 на ноду), не 100 000. Добавь распределённый лок, чтобы перейти от 50 к 1.

Композиция обоих слоёв

Ни один слой не достаточен сам по себе:

• Только single-flight: 50-нодный флот всё равно шлёт 50 параллельных rebuild.
• Только распределённый лок: ожидающие (все кроме 1 lock-holder-а) ничего не получают, пока rebuild идёт — добавляет латентность каждому запросу на границе.

Совмещённый стек:

1. Проверить in-process map → если Promise в полёте, подписаться и ждать.
2. Promise нет → попробовать SET lock:key uuid EX 30 NX.
3. Лок захвачен → зарегистрировать Promise, запустить rebuild, записать значение, удалить лок, resolve Promise.
4. Лок НЕ захвачен → ретрай GET кеша через 50 мс. Вернуть stale fallback, если всё ещё пусто.