Interactive
分散ロック可視化
分散ロックは「取得」は守れても「取得後の有効性」までは保証できません。Redlockクォーラムタブでは、N台のロックサーバーの状態（正常/低速/ダウン）を切り替えて、 過半数の取得とTTLに対する有効期限の計算を実際に試せます。GCポーズとフェンシングタブでは、クライアントの停止がTTLを超えたときにフェンシングトークンの有無でデータ破壊が起きるかどうかを、実際のタイムライン計算で比較できます。
ノードをクリックすると状態が「正常(20ms)→低速(300ms)→ダウン」の順に切り替わります。過半数（クォーラム）が応答し、かつ取得にかかった時間がTTLより十分短ければロック成立です。
ノード数 N
クォーラム閾値 ⌊5/2⌋+1 = 3 台
成功：ロックは有効
クォーラム 3/5台中 5台が応答（クォーラム達成）
取得時間 20ms / TTL 500ms → 残り有効期限 480ms
全ノードをダウンさせずに過半数を割ると（例: N=5で3台ダウン）、クォーラム自体に届かず即座に失敗します。逆に全ノードが応答しても、応答が遅く取得時間がTTLに迫ると「クォーラムは達成したのに有効期限がほぼ残っていない」状態になり得ます——記事の言う「多数決はロック取得の可用性を上げるが、取得後の停止には無力」という指摘の前段（取得そのものの余裕のなさ）を数値で確認できます。
すべてブラウザ内でクォーラム判定・タイムライン・トークン比較を実際に計算しています。実在のRedis/Redlock実装やネットワークは使っていません。
ここが分かる
- Redlockのクォーラムは⌊N/2⌋+1台。N=5なら3台、N=7なら4台が応答すれば取得成立——ノードをダウンさせて過半数を割ると、他の条件に関わらず即座に失敗することを確認できる。
- クォーラムに達しても取得にかかった時間がTTLに対して長すぎれば「有効期限がほぼ残っていない」状態になり得る——応答が遅いノードだけでクォーラムを構成すると、TTLを短くした時に成功から失敗へ切り替わることが実測できる。
- GCポーズがTTLより短ければ何も起きない。クライアント1は有効期限内に書き込みを終え、クライアント2が登場する余地自体がない。
- GCポーズがTTLを超えると、フェンシングなしではクライアント1の陳腐化した書き込みが後から届いてクライアント2の正当な書き込みを上書きする——フェンシングありでは保護リソース側が古いトークンを機械的に拒否し、この破壊を防ぐ。判定を「止まりうるクライアント」から「書き込みを受け取るリソース側」へ移すことが核心だという記事の主張を、実際のタイムライン計算で確認できる。