Redlockのリース時間とフェンシングの境界
Redisの条件付きリースとKleppmann、Sanfilippoの異なる議論を分ける。ロック取得と資源側の書き込み検査は同じ保証ではない。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
Redlockは時間の仮定の下でリースを調整し、フェンシングは資源側で要求順序を検査する別の機能だ。
実際の障害試験ではなく概念図だ。
保護する資源から考える
リースは限られた時間の調整であり、期限後の要求送信を自ら止めない。Redis文書は主ノードの取得後、非同期複製前に障害が起きる競争を説明する。ランダムな所有者値は他者のロックを解放しないための値で、全書き込みを順序付ける番号ではない。 Redisのモデル
仮の設計検討では操作を先に書く。誰が許可し、実行し、結果を受け入れるかは別の構成要素かもしれない。捨てられる計算結果の重複と基準レコードの二重変更では影響が違う。この比較は質問を定めるだけで、検証済みの実装や唯一の調整方法を選ぶものではない。
過半数取得は条件付きの時間枠
現行Redis文書は独立マスターへの並列取得を説明する。五台は例で、全配備の必須数ではない。過半数と経過時間を確認し、取得時間とドリフト余裕を引いた有効期間内に作業を終える必要がある。相対的な時計の進行についての仮定が付く。 取得と有効時間
仮の時間線で取得、残りのリース、資源への要求を分ける。数値がなくても遅い取得が作業時間を減らす関係は読める。成功応答と最終効果の把握も異なる。取得で終わる図は重要な後続操作を隠す。これは再試行や通信遅延の測定ではない。
専門家の議論はモデルが異なる
Martin Kleppmannは2016年2月8日のブログで、リースを超える停止や遅延要求から正しさに依存するRedlock利用を批判する。効率の議論はより単純なロックの推奨で、Redlockの承認ではない。Salvatore Sanfilippoの応答は限界のある相対時間モデルと取得時間の検査を擁護し、取得遅延と後続作業の超過を分ける。学術査読済みの証明や合意ではない。 Kleppmannの批判 Sanfilippoの応答
結論と仮定を一緒に読む。絶対時刻の一致と時計の進み方の許容範囲は別問題だ。取得時間の計算と停止した所有者の後続要求の阻止も違う。一つの答えを他の問題へ移さない。過去の時計API変更の意向は現実装の証拠ではない。
フェンシングは資源が見た順序に依存する
Kleppmannは増加トークンを資源が検査し、既に見た高い番号より古い要求を拒否する方式を説明する。解放用ランダム値とは異なり、保護資源の参加が必要だ。期限切れ所有者の即時一斉失効でも、自動的な直列化可能性でもない。 資源側の検査
仮の順序では、資源が新番号を見る前に旧要求が来ると、別の場所に新許可があるだけでは拒否できない。許可と到着の順序を別に描き、どこが比較して効果を実行するかを記す。確実な検査は実装で確認する条件で、記事の無条件な保証ではない。検査しない外部効果は別の境界として残る。
結論の前に仮定を検討する
現行Redisページは壁時計TTLの懸念を認め、フェンシングの検討を案内する。過去の二人のモデルが同じになった意味ではない。出典の日付と立場を分ける。 Redisの注意事項
許容する障害、時間仮定、超過時の動作、資源側検査、実際の証拠を表に記せる。不明を全環境の安全や危険という断定に置き換えない。一つの停止試験では全組合せを扱えず、未試験なら時間線を結果と呼ばない。この記事は概念と仮の比較であり、配備試験、形式証明、金融上の正しさの保証ではない。