{
  "index": 238,
  "slug": "editorial-2021-05-field-distributed-locks",
  "title": "Поздний владелец lease: как остановить stale write",
  "excerpt": "Истёкший lease не останавливает worker, который уже выполняет работу. Разбираем stale write, fencing token и атомарную проверку ресурса на конкретном interleaving.",
  "contentHtml": "<p>В журнале появляется странная последовательность: worker-B записал новое значение, а через несколько секунд worker-A вернул успешный ответ для той же записи. Команда видит два захвата одного lock и начинает менять TTL. Но часто provider не нарушал контракт. Worker-A получил lease, остановился на паузе, дождался expiry и продолжил работу. Ресурс принял его позднюю запись, потому что ничего не знал о поколении lock. Цена ошибки — откат состояния, повторная отправка платежа или потеря результата более нового worker.</p>\n<p>Тезис статьи простой: distributed lock координирует владельцев, но не защищает внешний ресурс от уже запущенного старого владельца. Для этой границы нужен fencing token. Worker передаёт token вместе с записью. Ресурс хранит последний принятый token и отклоняет меньший. Учебные значения, workers и времена ниже вымышлены. Пример работает в памяти и не доказывает поведение конкретного кластера.</p>\n<h2>Сначала разделите две ответственности</h2>\n<p>Lock authority отвечает на вопрос: «кому выдать следующее владение именем?». Lease даёт этому владению срок жизни. Keepalive продлевает срок, пока authority получает подтверждения от клиента.</p>\n<p>Защищаемый ресурс отвечает на другой вопрос: «может ли этот запрос изменить состояние после уже принятого поколения?». Здесь живёт compare-and-set, условный UPDATE, версия строки или другая транзакционная проверка. Если ресурс не выполняет такую проверку, token остаётся полем в логе.</p>\n<div class='table-scroll'><table><caption>Поколения владельцев на одной записи</caption><thead><tr><th scope='col'>Событие</th><th scope='col'>Состояние authority</th><th scope='col'>Состояние ресурса</th><th scope='col'>Ожидаемое решение</th></tr></thead><tbody><tr><td>A получил token 1</td><td>lease-A активен</td><td>последний token меньше 1</td><td>можно начать работу</td></tr><tr><td>lease-A истёк</td><td>имя можно выдать снова</td><td>A может ещё выполнять код</td><td>не считать A остановленным</td></tr><tr><td>B получил token 2</td><td>lease-B активен</td><td>token 2 ещё не принят</td><td>передать token 2 в write</td></tr><tr><td>B записал значение</td><td>authority может не участвовать</td><td>highest token равен 2</td><td>сохранить значение B</td></tr><tr><td>A прислал token 1</td><td>lease-A уже недействителен</td><td>highest token равен 2</td><td>отклонить stale write</td></tr></tbody></table></div>\n<h2>Как возникает stale write</h2>\n<p>Проверка lease в начале функции защищает только момент проверки. Она не переносится на будущую запись. Пауза может возникнуть из-за GC, медленной базы, debugger, сетевого ожидания или планировщика. За это время authority выдаст новое владение. Локальная переменная A всё ещё содержит старый leaseId, поэтому код продолжит работу, если перед write нет отдельного барьера.</p>\n<pre><code>t=0   A: acquire(lock) -&gt; token=1, lease=active\nt=4s  A: строит результат и останавливается\nt=5s  authority: lease A истёк\nt=5s  B: acquire(lock) -&gt; token=2\nt=6s  B: write(item, token=2) -&gt; accepted\nt=7s  A: write(item, token=1) -&gt; должен быть rejected</code></pre>\n<p>Последняя строка не исправляется повторной проверкой lock в A. Между такой проверкой и фактическим write снова появится окно. Ресурс должен проверить token в той же операции, которая меняет его состояние.</p>\n<h2>Минимальная защита на стороне ресурса</h2>\n<p>Учебная модель хранит два поля: значение и highest accepted token. Новый запрос проходит только при token больше сохранённого. Сравнение и запись должны быть атомарными относительно других writers. В SQL это обычно означает условие в одном UPDATE и проверку числа изменённых строк.</p>\n<pre><code>UPDATE jobs\nSET result = :result, accepted_fence_token = :token\nWHERE job_id = :job_id\n  AND accepted_fence_token &lt; :token;</code></pre>\n<p>Если UPDATE изменил ноль строк, запрос не получил право менять ресурс. Причины нужно различать: token мог быть старым, запись могла исчезнуть, а запрос мог повториться с тем же token. Не превращайте все нулевые результаты в retry. Повтор старого token не станет новым от повторной доставки.</p>\n<p>Равенство тоже важно. Условие <code>&lt;=</code> отвергает повтор с тем же поколением. Это не решает идемпотентность бизнес-операции. Для неё нужен отдельный operation id и журнал уже применённых эффектов. Owner, fence token и idempotency key отвечают на разные вопросы.</p>\n<figure><img src='/assets/editorial/2021/distributed-lock-diagnosis-2021.svg' alt='Дерево диагностики stale write: фиксируются resource key и token, затем различаются старый token, повтор операции, ошибочный release и отсутствие fencing' loading='lazy' /><figcaption>Диагностика начинается с состояния ресурса: без сохранённого highest token нельзя доказать, что поздний запрос был безопасно отклонён.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><caption>Матрица разбора конкурентной записи</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>Старый worker пишет после нового</td><td>Ресурс не проверяет token</td><td>Найти highest token до и после write</td><td>Добавить атомарное сравнение при записи</td></tr><tr><td>Старый worker снимает lock B</td><td>release ищет только по lock name</td><td>Сверить ownerId, leaseId и token</td><td>Освобождать только конкретный handle</td></tr><tr><td>Один результат применился дважды</td><td>Повтор доставки, а не stale generation</td><td>Сравнить operation id и effect ledger</td><td>Ввести отдельный idempotency contract</td></tr><tr><td>Оба запроса отклонены</td><td>Token относится не к той resource key</td><td>Сопоставить ключ конфликта и линию поколений</td><td>Сузить область lock и fencing до одного эффекта</td></tr><tr><td>Ошибку видят только по времени логов</td><td>Нет состояния решения на ресурсе</td><td>Проверить запись принятого token</td><td>Логировать решение рядом с условным write</td></tr></tbody></table></div>\n<h2>Release тоже должен быть условным</h2>\n<p>После expiry A может проснуться и отправить release. Если authority удаляет lock только по имени, A способен снять lease-B. Это отдельная ошибка. Fencing защищает запись ресурса, но не делает старый release безопасным.</p>\n<pre><code>release(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</code></pre>\n<p>Конкретный provider может использовать другой handle. Нельзя переносить названия полей как готовый API. Переносим только инвариант: старый владелец не должен менять состояние нового владельца.</p>\n<h2>Порядок проверки</h2>\n<ol><li>Остановите автоматический replay подозрительного request и сохраните reference на исходную операцию по правилам хранения данных.</li><li>Зафиксируйте одну resource key, ownerId, leaseId, fence token и highest token непосредственно до решения.</li><li>Воспроизведите interleaving: A получает token 1, lease истекает, B получает token 2, B пишет, A возвращается.</li><li>Проверьте, что запись B и проверка token 2 происходят атомарно в одной ресурсной границе.</li><li>Убедитесь, что поздний token 1 получает явный stale rejection и не меняет значение.</li><li>Повторите сценарий для release и проверьте, что handle A не освобождает lease B.</li><li>Отдельно проверьте duplicate operation по operation id. Не называйте этот результат доказательством fencing.</li></ol>\n<h2>Ограничения</h2>\n<p>Fencing не останавливает worker и не отменяет уже отправленный HTTP-запрос. Он не делает workflow exactly-once. Он не упорядочивает разные resource keys и не защищает внешний API, который не умеет принимать и проверять token. Для нескольких эффектов понадобятся разные контракты: fencing для одной записи, idempotency для повторного вызова, компенсация для уже принятого внешнего эффекта.</p>\n<p>Lease тоже не равен сигналу остановки процесса. В документации etcd expiry удаляет связанные ключи и освобождает lock, если сервер не получает keepalive. Документация не обещает отмену локальной функции клиента. Поэтому claim «lease истёк, A больше ничего не сделает» неверен.</p>\n<p>Эта статья не проверяет etcd, Redis, ZooKeeper, provider SDK, сеть, clock drift, cluster, нагрузку или production. Учебный interleaving показывает только нужный инвариант. Перед выпуском на реальном ресурсе нужно доказать, что его транзакция действительно отклоняет меньший token.</p>\n<h2>Критерий готовности</h2>\n<p>Работа готова, если интеграционный тест на выбранном ресурсе проходит четыре проверки: token 2 принимается; поздний token 1 не меняет значение; повторный token 1 получает явный отказ; старый release не снимает lease нового owner. В отчёте должны быть resource key, token до и после, причина отказа и сохранённое итоговое значение. Если хотя бы одного поля нет, тест подтверждает только наличие lock, но не защиту от stale write.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://etcd.io/docs/v3.6/dev-guide/api_concurrency_reference_v3/' target='_blank' rel='noopener noreferrer'>etcd v3.6: Concurrency API Reference — Lock и Unlock</a> — официальное описание lock key и освобождения lock через expiry связанного lease.</li><li><a href='https://etcd.io/docs/v3.6/dev-guide/api_reference_v3/' target='_blank' rel='noopener noreferrer'>etcd v3.6: API Reference — LeaseGrant и LeaseKeepAlive</a> — официальное описание TTL, keepalive и удаления связанных ключей после expiry.</li><li><a href='https://research.google/pubs/the-chubby-lock-service-for-loosely-coupled-distributed-systems/' target='_blank' rel='noopener noreferrer'>Mike Burrows, The Chubby lock service for loosely-coupled distributed systems</a> — первичная публикация об advisory locks и проверке sequencer защищаемым сервером.</li></ul>"
}