現在テスト中です: 完了後にGitHubのコードを公開する予定です。

リクエスト × キー状態マトリクス

A(獲得)

キー状態サーバーの動作レスポンスタイミング
未登録登録(有効期限 = 現在+lease)、トークン発行A+token+owner+key即座
登録済み + 期限切れ更新(現在+lease)、新しいトークンA+token+owner+key即座
登録済み + 有効なholder + wait=0queueへ入れないT+owner+key即時
登録済み + 有効なholder + wait>0queue登録、応答保留AまたはT+owner+keyrelease/expiryで獲得時、またはwait超過でT
queueまたはserver capacityが上限queueへ入れないB+owner+key即時
  • 解放の経路はFIFOで公平です: 保有者がRを行うと、キューの先頭にいる待機者へ 再競合なし・新しいトークンで直接引き継がれます。
  • 非FIFOなのは失効の経路だけです。
  • ownerが現在holderと同じでも特別扱いしません。active token返却やlease更新の権限ではなく、通常の保持中requestと同じ規則です。
  • 応答順はrequest順と異なり得るため、clientはechoされたownerでmatchします。 R(解放)
キー状態サーバーの動作レスポンス
登録済み + トークン一致、待機者あり先頭の待機者へ直接引き継ぎ(新しいトークン)R+token+key
登録済み + トークン一致、待機者なしキーを削除R+token+key
登録済み + トークン不一致何もしない(ロックは維持)N+token+key
未登録何もしないN+token+key

失効の処理タイミング

  • シングルモードは失効を遅延処理します — 期限切れのキーは次の獲得(上表の2行目)が その場で引き継ぎ、待機者のいない期限切れキーは別途5秒間隔の掃除で片付けられます。 そのため、期限切れだが未掃除のキーに対する解放はNではなくRになることがあります。
  • Cluster modeではleaderがtoken検証付きdeadline min-heapの次項目まで待ち、Expire commandをconsensus commitして初めてkeyが消えます。node間clock差でlock状態が分岐しないためです。