В журнале появляется странная последовательность: worker-B записал новое значение, а через несколько секунд worker-A вернул успешный ответ для той же записи. Команда видит два захвата одного lock и начинает менять TTL. Но часто provider не нарушал контракт. Worker-A получил lease, остановился на паузе, дождался expiry и продолжил работу. Ресурс принял его позднюю запись, потому что ничего не знал о поколении lock. Цена ошибки — откат состояния, повторная отправка платежа или потеря результата более нового worker.
\nТезис статьи простой: distributed lock координирует владельцев, но не защищает внешний ресурс от уже запущенного старого владельца. Для этой границы нужен fencing token. Worker передаёт token вместе с записью. Ресурс хранит последний принятый token и отклоняет меньший. Учебные значения, workers и времена ниже вымышлены. Пример работает в памяти и не доказывает поведение конкретного кластера.
\nLock authority отвечает на вопрос: «кому выдать следующее владение именем?». Lease даёт этому владению срок жизни. Keepalive продлевает срок, пока authority получает подтверждения от клиента.
\nЗащищаемый ресурс отвечает на другой вопрос: «может ли этот запрос изменить состояние после уже принятого поколения?». Здесь живёт compare-and-set, условный UPDATE, версия строки или другая транзакционная проверка. Если ресурс не выполняет такую проверку, token остаётся полем в логе.
\n| Событие | Состояние authority | Состояние ресурса | Ожидаемое решение |
|---|---|---|---|
| A получил token 1 | lease-A активен | последний token меньше 1 | можно начать работу |
| lease-A истёк | имя можно выдать снова | A может ещё выполнять код | не считать A остановленным |
| B получил token 2 | lease-B активен | token 2 ещё не принят | передать token 2 в write |
| B записал значение | authority может не участвовать | highest token равен 2 | сохранить значение B |
| A прислал token 1 | lease-A уже недействителен | highest token равен 2 | отклонить stale write |
Проверка lease в начале функции защищает только момент проверки. Она не переносится на будущую запись. Пауза может возникнуть из-за GC, медленной базы, debugger, сетевого ожидания или планировщика. За это время authority выдаст новое владение. Локальная переменная A всё ещё содержит старый leaseId, поэтому код продолжит работу, если перед write нет отдельного барьера.
\nt=0 A: acquire(lock) -> token=1, lease=active\nt=4s A: строит результат и останавливается\nt=5s authority: lease A истёк\nt=5s B: acquire(lock) -> token=2\nt=6s B: write(item, token=2) -> accepted\nt=7s A: write(item, token=1) -> должен быть rejectedПоследняя строка не исправляется повторной проверкой lock в A. Между такой проверкой и фактическим write снова появится окно. Ресурс должен проверить token в той же операции, которая меняет его состояние.
\nУчебная модель хранит два поля: значение и highest accepted token. Новый запрос проходит только при token больше сохранённого. Сравнение и запись должны быть атомарными относительно других writers. В SQL это обычно означает условие в одном UPDATE и проверку числа изменённых строк.
\nUPDATE jobs\nSET result = :result, accepted_fence_token = :token\nWHERE job_id = :job_id\n AND accepted_fence_token < :token;Если UPDATE изменил ноль строк, запрос не получил право менять ресурс. Причины нужно различать: token мог быть старым, запись могла исчезнуть, а запрос мог повториться с тем же token. Не превращайте все нулевые результаты в retry. Повтор старого token не станет новым от повторной доставки.
\nРавенство тоже важно. Условие <= отвергает повтор с тем же поколением. Это не решает идемпотентность бизнес-операции. Для неё нужен отдельный operation id и журнал уже применённых эффектов. Owner, fence token и idempotency key отвечают на разные вопросы.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Старый worker пишет после нового | Ресурс не проверяет token | Найти highest token до и после write | Добавить атомарное сравнение при записи |
| Старый worker снимает lock B | release ищет только по lock name | Сверить ownerId, leaseId и token | Освобождать только конкретный handle |
| Один результат применился дважды | Повтор доставки, а не stale generation | Сравнить operation id и effect ledger | Ввести отдельный idempotency contract |
| Оба запроса отклонены | Token относится не к той resource key | Сопоставить ключ конфликта и линию поколений | Сузить область lock и fencing до одного эффекта |
| Ошибку видят только по времени логов | Нет состояния решения на ресурсе | Проверить запись принятого token | Логировать решение рядом с условным write |
После expiry A может проснуться и отправить release. Если authority удаляет lock только по имени, A способен снять lease-B. Это отдельная ошибка. Fencing защищает запись ресурса, но не делает старый release безопасным.
\nrelease(lockName, leaseId, ownerId, token)\n if active.lockName != lockName: reject\n if active.leaseId != leaseId: reject\n if active.ownerId != ownerId: reject\n delete activeКонкретный provider может использовать другой handle. Нельзя переносить названия полей как готовый API. Переносим только инвариант: старый владелец не должен менять состояние нового владельца.
\nFencing не останавливает worker и не отменяет уже отправленный HTTP-запрос. Он не делает workflow exactly-once. Он не упорядочивает разные resource keys и не защищает внешний API, который не умеет принимать и проверять token. Для нескольких эффектов понадобятся разные контракты: fencing для одной записи, idempotency для повторного вызова, компенсация для уже принятого внешнего эффекта.
\nLease тоже не равен сигналу остановки процесса. В документации etcd expiry удаляет связанные ключи и освобождает lock, если сервер не получает keepalive. Документация не обещает отмену локальной функции клиента. Поэтому claim «lease истёк, A больше ничего не сделает» неверен.
\nЭта статья не проверяет etcd, Redis, ZooKeeper, provider SDK, сеть, clock drift, cluster, нагрузку или production. Учебный interleaving показывает только нужный инвариант. Перед выпуском на реальном ресурсе нужно доказать, что его транзакция действительно отклоняет меньший token.
\nРабота готова, если интеграционный тест на выбранном ресурсе проходит четыре проверки: token 2 принимается; поздний token 1 не меняет значение; повторный token 1 получает явный отказ; старый release не снимает lease нового owner. В отчёте должны быть resource key, token до и после, причина отказа и сохранённое итоговое значение. Если хотя бы одного поля нет, тест подтверждает только наличие lock, но не защиту от stale write.
\nСимптом в журнале часто выглядит противоречиво: worker-B успешно записал новый результат, а потом worker-A сообщил об успешной обработке того же предмета. Цена поспешного диагноза высока. Можно обвинить provider в «двойном lock», увеличить TTL и пропустить факт, что ресурс принял поздний request без проверки поколения. После следующей паузы ошибка повторится, но лог будет содержать ещё больше лишних объяснений.
\nДля разбора нужен небольшой пакет доказательств, а не догадка о точности часов. Сохраняем lockName, ownerId, leaseId, fenceToken, порядок учебных событий, highest token ресурса до и после write и результат проверки. Этого достаточно, чтобы отличить stale owner от duplicate операции или старого release. Все workers, lease, token, значения ресурса и времена ниже учебные. Модель работает только с Map и счётчиком времени в памяти: она не запускает etcd, Redis, ZooKeeper, базу, broker, HTTP, сетевой тест, синхронизацию часов или cluster.
\nПервое действие при подозрении на stale write — не делать automatic retry. Если request с token 1 уже пришёл после принятого token 2, повтор token 1 не станет новее. Он должен получить тот же явный отказ. Нужна запись, которая связывает один request с одним поколением и состоянием ресурса в момент решения. В учебном примере это обычный объект; в рабочем коде состав полей зависит от политики данных и от того, где живёт ресурсная транзакция.
\nconst evidence = {\n lockName: 'report:417:rebuild',\n ownerId: 'worker-A',\n leaseId: 'training-lease-1',\n fenceToken: 1,\n resourceHighestTokenBefore: 2,\n result: 'rejected-stale-fence',\n};\n\n// Такой пакет объясняет отказ без вывода о точности реальных часов.Поле resourceHighestTokenBefore особенно полезно. Если оно уже равно 2, а request несёт 1, причина отказа читается без предположения «worker-A точно спал шесть секунд». Мы видим, что ресурс уже принял более новое поколение. Если highest token ещё 0, ситуация другая: возможно, новый owner не успел записать, либо request ушёл к другому resource key. Эти ветви нельзя склеивать в одну метку lock-error.
| Наблюдение | Вероятная граница | Что проверить | Следующее действие |
|---|---|---|---|
| token 1 пришёл после accepted token 2 | resource-side fencing работает | один resource key и strict comparison | вернуть stale result, не повторять старый write |
| A release снимает lock B | release не связан с handle | leaseId и owner current lease | сверять точный lease handle перед delete |
| оба write приняты | resource не хранит или не сравнивает token | условие в той же операции, что и write | добавить resource-side fencing или сузить действие |
| token 1 и token 2 попали в разные keys | неверная область fencing | resource key и доменная граница | согласовать один key на один конфликтующий эффект |
| один token повторился | delivery/idempotency, не обязательно stale owner | operationId и effect ledger | разобрать duplicate отдельным contract |
Таблица намеренно не содержит строку «синхронизировать часы и закрыть задачу». Время помогает восстановить порядок, но fence не должен полагаться на timestamp worker. При записи значение token сравнивается внутри ресурса. Если в диагностике есть только wall-clock логи, а resource не записывает принятую версию, вы не сможете доказать, был ли поздний request опасен или просто пришёл после другого несвязанного события.
\nВ fixture история короткая и детерминированная. Worker-A берёт training-lease-1 с token 1. Модель переводит clock в 6000 мс и отмечает lease истёкшим. Worker-B получает training-lease-2, token 2 и записывает v2. Потом A возвращается с v1. Ресурс смотрит на свой highest token, а не на память A, и возвращает rejected-stale-fence.
const fixture = runDistributedLockFixture();\nif (!Object.values(fixture.assertions).every(Boolean)) {\n throw new Error('training lock contract failed');\n}\n\nconsole.log(fixture.timeline.staleFirstWrite.status);\n// rejected-stale-fenceТакой тест не проверяет фактический provider. Он проверяет, что команда не потеряла нужный сценарий в обсуждении. Если кто-то заменит сравнение <= на безусловный write, assertion protectedResourceRetainedNewerValue перестанет выполняться. Если убрать resource check, unsafe contrast покажет старое значение в финале. Это хороший маленький барьер перед интеграционным тестом, но не замена ему.
Истечение lease означает только, что authority больше не считает этот захват активным. Оно не завершает функцию в worker-A, не отзывает переменную leaseId из памяти и не гарантирует отмену уже отправленного request. Это особенно заметно, если дорогое вычисление построило payload до паузы, а HTTP-клиент продолжил отправку после неё. Поэтому фраза «lease истёк, значит A уже ничего не сделает» не должна попадать в runbook.
Документация etcd v3.4 формулирует это со стороны lock: при expiry lease относящиеся к нему keys удаляются и lock освобождается. Она не описывает отмену работы клиента и не добавляет проверку к внешнему write. Исторический Chubby paper отдельно называет locks advisory и описывает sequencer, который получатель запроса должен проверить. Эти два источника полезны именно потому, что не скрывают границу в удобной фразе «взяли блокировку».
\nИногда stale write уже защищён fence, но после него lock неожиданно свободен. Тогда смотрим не на token ресурса, а на release. Worker-A мог сохранить handle старого захвата и после pause послать delete по одному lockName. Если authority принимает такую операцию, A способен снять lease-2 worker-B. Это не отменяет fencing у ресурса, но создаёт новую конкуренцию для последующих worker.
function releaseCurrent(active, request) {\n const ownsCurrentLease = active.ownerId === request.ownerId\n && active.leaseId === request.leaseId\n && active.fenceToken === request.fenceToken;\n\n return ownsCurrentLease ? { status: 'released' }\n : { status: 'release-rejected-not-owner' };\n}\n\n// Старый worker-A не должен снять lease-2, выданный worker-B.В учебной модели release содержит owner, leaseId и token. Модель не даёт старому A удалить активный B и фиксирует release-rejected-not-owner. Конкретный provider может использовать другой handle и другое API; не переносите поля буквально. Инвариант остаётся: release должен быть условным по идентификатору того владения, которое будет освобождено, а не только по имени предмета.
Fence предотвращает старое поколение write для того ресурса, который его проверяет. Он не делает весь workflow exactly-once, не отменяет письмо, уже принятое внешним API, и не определяет порядок между разными resource keys. Если операция создаёт несколько эффектов, у каждого должен быть свой контракт: один ресурс может держать token, другой — operation id, третий — явное ручное решение. Одна блокировка вокруг всего процесса не заменяет эту работу.
\n| Вопрос | Покрывает ли token? | Нужный дополнительный механизм |
|---|---|---|
| поздний write token 1 после token 2 в одном ресурсе | да, если ресурс сравнивает token атомарно | хранение highest token рядом с write |
| старый worker снимает новый lease | нет | условный release по текущему handle |
| повтор одного внешнего вызова | нет | operation id и idempotency contract получателя |
| два разных resource key в одном workflow | не сам по себе | явная модель порядка или компенсации |
| worker действительно остановлен после expiry | нет | cancellation/timeout как отдельная локальная дисциплина |
Эта граница не делает lock бесполезным. Lease полезен, чтобы не запускать одну дорогую работу одновременно, а fence полезен, чтобы поздняя работа не стала новым состоянием там, где ресурс умеет сравнение. Ошибка начинается, когда один механизм получает чужое обещание. Особенно опасно обобщение «мы используем distributed lock, значит транзакция защищена»: оно скрывает, какой именно write ресурс обязан отклонять.
\nПосле успешно пройденного сценария можно сказать узко: ресурс отклонил учебный поздний request token 1 после принятого token 2, а старый handle не освободил новый lease. Нельзя сказать, что provider безопасен при любой сети, часы корректны, кластер выдержал partition или бизнес-эффект exactly-once. Честный результат меньше по масштабу, зато даёт проверяемую границу следующему изменению.
\nЗдесь не запускались реальные etcd/Redis/ZooKeeper, база, provider SDK, сеть, синхронизация времени, cluster, external API, browser, CI, production build, deployment или нагрузка. Нет настоящих пользовательских данных и claim о SLA. Следующий шаг — воспроизвести тот же порядок против конкретного ресурса: зафиксировать способ выдать упорядоченный token, доказать атомарное сравнение на write и проверить поведение старого release. Без этой тройки лог о lock остаётся наблюдением, но не гарантией.
\n