Симптом в журнале часто выглядит противоречиво: 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