現在テスト中です: 完了後にGitHubのコードを公開する予定です。
リクエスト × キー状態マトリクス
A(獲得)
| キー状態 | サーバーの動作 | レスポンス | タイミング |
|---|
| 未登録 | 登録(有効期限 = 現在+lease)、トークン発行 | A+token+owner+key | 即座 |
| 登録済み + 期限切れ | 更新(現在+lease)、新しいトークン | A+token+owner+key | 即座 |
登録済み + 有効なholder + wait=0 | queueへ入れない | T+owner+key | 即時 |
登録済み + 有効なholder + wait>0 | queue登録、応答保留 | AまたはT+owner+key | release/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状態が分岐しないためです。