![\"Схема](\"/assets/editorial/2021/distributed-lock-fence-boundary-2021.svg\")
В журнале появляется странная последовательность: worker-A получил lock, надолго замолчал, worker-B получил тот же ресурс и записал новый результат, а затем A проснулся и тоже получил успешный ответ на запись. В базе снова лежит старое значение. В очереди возникла повторная команда. Внешний API принял действие от процесса, который уже не владел именем ресурса.
\nЦена ошибки — не только одна неверная строка. Команда может решить, что lock-сервис выдал два владения одновременно, увеличить TTL и оставить настоящую дыру. Старый процесс не обязан знать, что его lease истёк. Проверка «lock был захвачен в начале» не защищает операцию, которая завершается позже.
\nТезис: lease отвечает за координацию владельцев, а fencing token защищает финальную запись. Ресурс должен хранить последнее принятое поколение и атомарно отклонять запрос с меньшим или равным token. Все worker, lease, token и времена ниже учебные: пример не запускает etcd, Redis, ZooKeeper, базу или сеть.
\nLock authority отвечает: «кому сейчас выдано владение именем?» Он может выдать lease-1 worker-A, дождаться expiry и выдать lease-2 worker-B. Lease ограничивает время владения. Keepalive продлевает его только пока authority получает подтверждения.
\nЗащищаемый ресурс отвечает иначе: «можно ли этому запросу изменить моё состояние после уже принятого поколения?» Ресурсом может быть строка в базе, объектное хранилище, файл или сервер, который принимает команду. Если он не проверяет поколение сам, наличие lock в другом сервисе не влияет на его решение.
\n| Событие | Знает authority | Знает ресурс | Действие |
|---|---|---|---|
| A получил token 1 | lease-1 активен | ничего | передать token вместе с записью |
| lease-1 истёк | имя доступно | A всё ещё может ждать | не считать A остановленным |
| B получил token 2 | lease-2 активен | ничего | передать token вместе с записью |
| ресурс принял token 2 | может не участвовать | highest token равен 2 | сохранить новое значение |
| поздний запрос A с token 1 | может видеть lease-2 | token 1 устарел | отклонить запись |
Ресурсу не нужно снова спрашивать authority, жив ли lease-A. Такой запрос добавляет сетевой вызов и новую гонку. Достаточно собственного факта: token 2 уже принят для этого resource key. Это узкая гарантия. Она не останавливает A и не делает всю бизнес-операцию exactly-once.
\nПри каждом новом захвате authority выдаёт монотонное поколение. Token 1 относится к lease-A, token 2 — к lease-B. Request несёт token до точки, где появляется эффект. Ресурс хранит acceptedFenceToken. Условие записи выглядит так:
function write(resource, request) {\n if (request.fenceToken <= resource.acceptedFenceToken) {\n return { status: 'rejected-stale-fence' };\n }\n resource.acceptedFenceToken = request.fenceToken;\n resource.value = request.value;\n return { status: 'accepted' };\n}Это псевдокод. В SQL условие и присваивание должны быть одной операцией, например UPDATE ... SET value = $1, fence_token = $2 WHERE id = $3 AND fence_token < $2. По числу изменённых строк видно, принял ли ресурс запрос. Отдельное чтение token, пауза и последующий write оставляют ту же гонку.
Строгое сравнение важно. Равный token не делает request новым. Повтор доставки с тем же token требует отдельного operationId и идемпотентного журнала. ownerId показывает автора, leaseId связывает release с конкретным захватом, fenceToken задаёт порядок поколений, а operationId различает повторы одной операции.
Пусть A получил token 1 и начал расчёт. Расчёт должен был занять меньше lease, но процесс остановился на сборке мусора или на медленном вызове базы. Lease истёк. B получил token 2, закончил расчёт и записал v2. A продолжил работу и отправил уже вычисленный v1.
t=0 A: acquire(resource-7) -> lease-A, token=1\nt=5 A: compute() -> процесс остановился\nt=10 authority: lease-A expired\nt=11 B: acquire(resource-7) -> lease-B, token=2\nt=12 B: write(v2, token=2) -> accepted; highest=2\nt=13 A: write(v1, token=1) -> rejected; highest=2Небезопасный ресурс делает иначе:
\nresource.value = 'v2'; // B\nresource.value = 'v1'; // A: поздняя запись проходитЗдесь ресурс не знает о lock и не отличает старый запрос от нового. Лог о том, что A когда-то владел lock, не исправит данные после записи. Если API не предоставляет условную запись, версию или серверную проверку, перенесите эффект на контролируемую транзакционную границу либо явно примите, что lock только координирует работу.
\n| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Старый worker получил 200 после нового | ресурс не проверяет token | сравнить token запроса и highest token | добавить атомарный reject stale write |
| Старый release снял lock B | release проверяет только имя | сверить owner, leaseId и token текущего захвата | отклонять старый handle |
| После retry получился duplicate | fencing принят за идемпотентность | найти operationId и журнал эффекта | добавить идемпотентный контракт отдельно |
| Растёт доля busy | lease не продлевается или ресурс долго занят | разделить acquire, keepalive и write latency | настроить TTL по измерениям, не скрывать отказ |
| Нет token в запросе ресурса | граница защиты осталась в authority | проследить поля до финального write | передавать и сохранять поколение на ресурсе |
resource key и финальный write, который создаёт риск. Не прячьте несколько ресурсов за одним общим lock name.stale, а не успешный ответ или общий timeout.Fencing не отзывает уже выполняющийся код. Он не отменяет запрос, ушедший без проверки, и не исправляет запись, принятую до добавления правила. Он не гарантирует согласованность между двумя независимыми ресурсами. Для нескольких записей нужна общая транзакционная граница, протокол саги или другая выбранная модель.
\nKeepalive сокращает вероятность expiry во время нормальной работы, но не доказывает, что поздний request безопасен. Между подтверждением lease и финальным write остаются паузы, сетевые разрывы и очереди. Provider key тоже не становится fencing token автоматически: важны порядок поколений и проверка на стороне получателя.
\nУчебные фрагменты не дают production-результатов. Они не измеряют задержки, clock drift, SLA, пропускную способность или поведение кластера. Проверяемый критерий готовности таков: после принятого token 2 любой запрос с token 1 получает явный stale-результат, значение ресурса остаётся результатом token 2, а старый release не меняет lease B.
\nНа дежурстве инженер увидел странный порядок в логе: worker-A получил lock, надолго замолчал, worker-B дождался освобождения ресурса и записал новый результат, а затем A проснулся и тоже получил успешный ответ. В базе снова оказалось старое значение. Похожий след появляется у очереди, когда повторная команда проходит от процесса, который уже потерял право менять состояние.
\nЦена ошибки — не только одна неверная строка. Команда может решить, что сервис блокировок выдал два владения одновременно, увеличить TTL и оставить настоящую дыру. Lease ограничивает время владения, но не возвращает процесс назад и не отменяет запрос, который уже ушёл к ресурсу. Поэтому проверка «lock был захвачен в начале» не защищает операцию, которая завершается позже.
\nРабочее правило: lease отвечает за координацию владельцев, а fencing token защищает финальную запись. Ресурс хранит последнее принятое поколение и атомарно отклоняет запрос с меньшим или равным token. Все worker, lease, token и времена ниже учебные: пример не запускает etcd, Redis, базу или сеть.
\nВ гонке легко назвать все значения «токеном» и потерять смысл каждого поля. ownerId обозначает процесс, leaseId связывает его с конкретным захватом, fenceToken задаёт порядок поколений, а operationId позволяет распознать повтор одной бизнес-операции. Эти поля не заменяют друг друга.
| Поле | Кто выдаёт или создаёт | Где проверяется | Какую проблему решает |
|---|---|---|---|
ownerId | worker или его экземпляр | лог и диагностика | показывает, кто отправил запрос |
leaseId | lock authority | release и контракт владения | не даёт старому handle снять новый lease |
fenceToken | authority с монотонным счётчиком | защищаемый ресурс | отбрасывает позднее поколение |
operationId | доменная операция | журнал эффекта или API | отличает повтор доставки от новой операции |
Lock authority отвечает на вопрос «кому сейчас выдано имя?». Он может выдать lease-1 worker-A, дождаться истечения и выдать lease-2 worker-B. Защищаемый ресурс отвечает на другой вопрос: «можно ли этому запросу менять моё состояние после уже принятого поколения?». Если ресурс не проверяет поколение сам, наличие lock в другом сервисе не влияет на его решение.
\nПусть A получил lease и fenceToken=41, после чего начал расчёт. Расчёт должен был завершиться раньше TTL, но процесс остановился на сборке мусора или на медленном вызове базы. Authority признал lease истёкшим. B получил новое поколение 42, закончил расчёт и записал v2. Когда A продолжил работу, в его памяти всё ещё был результат v1.
t=0 A: acquire(resource-7) -> lease-A, fenceToken=41\nt=5 A: compute() -> процесс остановился\nt=10 authority: lease-A expired\nt=11 B: acquire(resource-7) -> lease-B, fenceToken=42\nt=12 B: write(v2, token=42) -> accepted; highest=42\nt=13 A: write(v1, token=41) -> rejected; highest=42Небезопасный ресурс делает иначе:
\nresource.value = 'v2'; // B\nresource.value = 'v1'; // A: поздняя запись проходитЛог о том, что A когда-то владел lock, не исправит данные после записи. Проверка «lease ещё жив?» непосредственно перед записью тоже не является достаточной: между чтением статуса и отправкой эффекта может пройти пауза. Решение должно находиться на той же границе, где ресурс принимает изменение.
\nПри каждом новом захвате конкретного resourceKey authority выдаёт большее поколение. Ресурс хранит acceptedFenceToken рядом с защищаемым состоянием. Условие простое: принять запрос можно только при request.fenceToken > acceptedFenceToken. После принятия ресурс в одной атомарной операции обновляет и данные, и сохранённое поколение.
function write(resource, request) {\n if (request.fenceToken <= resource.acceptedFenceToken) {\n return { status: 'rejected-stale-fence' };\n }\n\n resource.acceptedFenceToken = request.fenceToken;\n resource.value = request.value;\n return { status: 'accepted' };\n}Это псевдокод, а не готовая транзакция. Для одной строки PostgreSQL условие и присваивание можно выразить так:
\nUPDATE resource_state\nSET value = $1, fence_token = $2\nWHERE resource_key = $3\n AND fence_token < $2;Смотрите на число изменённых строк: ноль означает, что запрос не прошёл условие или ресурс уже обработал более новое поколение. Отдельное чтение token, пауза и последующий UPDATE оставляют ту же гонку. Поле fence_token должно переживать перезапуск и не сбрасываться вместе с памятью worker-а; иначе старый token может снова стать «новым».
В etcd lease живёт ограниченное время: кластер удаляет связанные ключи после истечения lease, если keep-alive не пришёл. Concurrency Lock возвращает ключ владения, который существует, пока lock удерживается; его можно использовать в транзакции для защиты изменений внутри самого etcd. Это полезная координация, но ключ lock или обычный leaseId не превращается автоматически в fencing token для внешней базы, файла или API.
Для внешнего ресурса нужен отдельный контракт. Authority должен выдать монотонное поколение, worker обязан передать его в запросе, а ресурс — проверить и записать результат атомарно. В работе Chubby эту роль выполняет sequencer: сервер-получатель проверяет, что последовательность всё ещё действительна, и отклоняет операцию с устаревшим состоянием. Название поля может быть другим, но граница остаётся той же.
\n| Шаг | Состояние authority | Состояние ресурса | Ожидаемый результат |
|---|---|---|---|
| A захватил ресурс | lease-A активен, token 41 | последний token 40 | A может начать работу |
| lease-A истёк | имя можно выдать снова | A может продолжать вычисление | старый процесс не считается остановленным |
| B захватил ресурс | lease-B активен, token 42 | последний token 40 | B передаёт 42 в финальный write |
| B записал | может не участвовать | token 42 и v2 | ресурс принимает изменение |
| A записал поздно | может видеть новый lease | 41 меньше 42 | ресурс отвечает stale |
Если операция меняет несколько строк, условие должно защищать одну выбранную транзакционную границу. Несколько независимых UPDATE не превращаются в атомарную бизнес-операцию только потому, что в каждом есть token. Для внешнего API нужны его условная запись, идемпотентный ключ или другая явно выбранная гарантия.
| Симптом | Вероятная причина | Проверка | Действие |
|---|---|---|---|
| Старый worker получил успех после нового | ресурс не проверяет token | сравнить token запроса с сохранённым | добавить атомарный reject устаревшего write |
| Старый release снял lock B | release проверяет только имя | сверить owner, leaseId и handle текущего захвата | отклонять старый handle |
| Повтор создал второй эффект | fencing приняли за идемпотентность | найти operationId и записи эффекта | добавить идемпотентный контракт отдельно |
| Token повторился после рестарта | счётчик жил только в памяти | сравнить историю выдачи и состояние authority | сделать источник поколений долговечным |
| Запрос ресурса не содержит token | граница защиты осталась в authority | проследить поля до финального write | передавать и проверять поколение на ресурсе |
resourceKey и финальный write, который создаёт риск. Не прячьте несколько независимых ресурсов за одним общим lock name.stale, а не успешный ответ или общий timeout.operationId. Fencing задаёт порядок владельцев, но не отвечает за повтор одного бизнес-эффекта.Fencing не отзывает уже выполняющийся код. Он не отменяет запрос, ушедший без проверки, и не исправляет запись, принятую до добавления правила. Он не гарантирует согласованность между двумя независимыми ресурсами. Для нескольких записей нужна общая транзакционная граница, протокол саги или другая выбранная модель.
\nKeepalive уменьшает вероятность истечения lease во время нормальной работы, но не доказывает безопасность позднего request. Между подтверждением lease и финальным write остаются паузы, сетевые разрывы и очереди. Счётчик тоже не становится fencing token автоматически: важны монотонный порядок, долговечность и проверка на стороне получателя.
\nУчебные фрагменты не дают измерений задержки, clock drift, SLA или пропускной способности кластера. Критерий готовности уже конкретнее: после принятого token 42 любой запрос с token 41 получает явный stale-результат, значение ресурса остаётся v2, старый release не меняет lease B, а повтор с тем же operationId не создаёт второй эффект.
Вернитесь к сцене из начала: перед увеличением TTL сначала найдите финальный ресурс и проверьте, доходит ли до него поколение. Если поля нет или ресурс не умеет условную запись, lock по-прежнему только координирует worker-ы; защиту нужно добавить именно на границе эффекта.
\nWHERE, результату обновления и числу изменённых строк.