要点: 分散ロックだけでは、停止や通信断の後もプロセスが所有権を持つと証明できません。
この記事の用語: Lease：期限付きの所有権。Fencing Token：古い担当者の書き込みを拒否する単調増加番号。
現場の課題
プロセスがLeaseの期限を超えて停止し、別プロセスが所有権を得た後に古い処理が再開することがあります。書き込み先自身が古い所有権を拒否しなければなりません。
GC停止や通信断がLeaseより長いと、古いプロセスが権限喪失を知らず再開します。Fencing Tokenを資源側で比較し、古い書き込みを拒否します。
設計と実装
- まずパーティション分割や冪等性で、共有所有責任そのものを減らします。
- 期限付きLeaseと、取得ごとに増加するFencing Tokenを発行します。
- 書き込み先で、最後に受け取った値より小さいトークンを必ず拒否します。
実装例
lease = coordinator.acquire(resourceId, ttl = 10s)
result = compute(deadline = lease.expiresAt - 2s)
UPDATE resource
SET value = :result, fence = :token
WHERE id = :id AND fence < :token本番導入の進め方
まず冪等性や楽観Lockを試し、本当に単一担当者が必要な処理だけへFencingを入れます。障害時に使える安全な直列処理経路も残します。
まとめ
分散ロックは処理を調整しますが、担当者変更後の正しさを守るのは書き込み先のFencingです。