これは、もともと設計さRedisのの本来の意図ではないので、今、ますますRedisのデータ管理に使用されている小型のシリーズは、この領域は、彼が心配感じさせるより多くのデータの一貫性と耐久性を必要とする（実際にはこれは、プログラマ産業の多くがありますミス、分散ロックRedisの一つを気に基づいている、使用中のRedisのデータベース）のようなより多く。
マーティンはあなたが分散ロックを使用する理由のすべての最初のパフォーマンスや正確性のために、明確でなければならないと指摘しましたか？あなたは、次の質問を自問することができたときにロックが失敗した2、区別しやすくするには：
パフォーマンスに：あなたは努力の重複されませんように、それはロックが失敗した場合、2つのノードがこの仕事をしながら、その後、仕事をあなたの費用に加え、（例えば、ジョブが二回行われる）ロックされています。
正確に：ロックが同時操作は、システムやデータを汚染し、データを操作し、同時に2つのノードならば、ロックが失敗しないようにして、結果が矛盾したデータ、データの損失、ファイルの競合かもしれ深刻につながります結果。
どちらも、右のシーンのロックを必要としていますが、ロック分散何らかの理由でその必要性を認識しておく必要があり上回っています。
あなただけのパフォーマンスをした場合、それから、メインハングを防ぐためにRedlock、その高いコストと複雑さ、あなただけの一例に十分な、プラスアップのRedisを使用する必要はありません。もちろん、あなたは電源オフ後、単一ノードのRedisを使用するか、またはいくつかのケースでは、あなたはロックを失いますが、あなたの目的は、事のパフォーマンスと電源オフの種類が頻繁に発生しません、これは大きな問題ではありません加速することです。あなたは、単一ノードのRedisを使用する場合と、あなたがこのアプリケーションを必要とすることは明らかであるロック粒度は、重要なサービスが何であるか、荒い非常にあいまいではありません。
シーンの正確性についてRedlock要件が優れているかどうかそう？いくつかのシーンを列挙マーティンは、このアルゴリズムは信頼に欠けることが判明したRedlock。
リソースを保護するためのロック
この詩最初Redlockマーティンは脇に置くだけ分散ロックは、それがどのように動作するか、一般的に議論します。分散環境では、それは別のノードを含むので、ミューテックスは、このようなより複雑なロック、ネットワーク通信、彼らは失敗する兆候の対象となっています。マーティンは、それが最初のアプリケーションがロックされ、その後、ファイルを書き戻し、変更された、シナリオ、ファイルを変更するには、クライアントを想定し、ロックを置きます。次のように別のクライアントアプリケーションは、...ロックコードの流れは次のとおりです。
//このコードは、壊れて
機能書き込みデータ（ファイル名、データ）{
VARロック= lockService.acquireLock（ファイル名）。
（！ロック）{場合
投げる「ロックの取得に失敗しました」;
}
{試みる
varファイル= storage.readFile（ファイル名）。
VAR更新=のupdateContents（ファイル、データ）;
storage.writeFile（ファイル名、更新）;
}最後に{
lock.release（）。
}
}
なぜ残念ながら、あなたはサービスが完璧だったロックしても、上記のコードはまだひざまずいて、以下のフローチャートはあなたを教えてくれます。
図は、上記の時間の休止期間、例えばGC休止時ロックCLIENT1を保持しているロックを取得します。GCの休止が長すぎるリース時間ロックにわたり、その後、別のロックが取得されたCLIENT2、元CLIENT1が知覚されていない場合のロック時間（通常は常にクラッシュ後にロックを果たしてきたクライアントを防ぐために、リースと呼ばれる）の有効期限が切れますが、い期限切れのロックする、奇妙な結果が発生し、HBaseのはこの起こるバグを持っています。チェックインの場合でも、CLIENT1はライトバックする前にロックが期限切れになったGCはいつでも発生する可能性があるので、あなたが（書き込み操作中に、最後のチェックイン時に）非常に不便があっても、問題を解決する助けにはなりません。あなたのプログラムが長いGCの一時停止を持っていないと思われる場合、他の理由あなたのプロセスの一時停止があります。その上、または他のSIGSTOP事故と、あなたはまた、ネットワークサービスに依存してもよい;または他のプロセスがCPUを使用しているたとえば、プロセスはまだそれがページフォールトを取得しますので、データメモリに読み込まれ、キャッシュにロードするページを待たないかもしれません。
... ....ここでマーティンは、上記のコードは関係なく、あなたのロックは完璧以上を提供し、安全ではないではありませんことを証明するために、プロセス中のポーズの様々な例を挙げました。
ロックが安全になるようにフェンシング（フェンス）を使用します
問題を解決する方法は非常に簡単です：あなたはたびに、書き込み動作をフェンシングトークンを追加する必要があります。このシナリオでは、フェンシングのトークンは、増分番号（ロックサービスを行うことができます）、クライアントアプリケーションロックが一度インクリメントされるたび場合があります
CLIENT1アプリケーションは、それが長い休止ロックも期限切れになり、token33を取得し、同じ時間をロックします。クライアント2がロックされ、すぐにCLIENT1生き後にデータを書き込むための書き込みデータの試行さtoken34、書き込み動作時より34小さいそのtoken33は、したがって、拒否されます。これはトークンをチェックするストレージ層を必要とするが、達成することは困難ではないことに注意してください。あなたがロックサービスとして飼育係を使用する場合は、増分数としてzxid使用することができます。しかし、あなたが知っているRedlockのために、生成されたものは、トークンの道をフェンシングない、とどのようにそれをトークンフェンシングを生み出すことができるようにRedlockアルゴリズムを変更するには？それはとても明白でいないようです。単調に増加する必要がトークンを生成しているため、単一ノードのRedisで行わしかし、これは何の高い信頼性を持っていない場合を除き、あなたはRedlockが信頼フェンシングトークンを生成するためにコヒーレンス・プロトコルを持参する必要があるように見えます。
一貫性を解決するために時間を使って
その理由は、シーンにその需要の正しさを放棄しなければならないトークンを生成フェンシングないRedlockが、議論する価値があるいくつかの場所があります。
アカデミアは、ことわざがあり、時間アルゴリズムの仮定をしない：プロセスは、いくつかの時間のために一時停止する可能性があるため、パケットはクロックかもしれ単に間違っている、なぜならネットワークの遅延の遅延到着するかもしれません。そして、信頼性の高いアルゴリズムは、まだ上記の仮定の下で、正しいことをしたいです。
故障検出器であるため、ノードのための基礎が失敗として、タイムアウトが唯一、なぜならネットワークの待ち時間の他の理由のために制限を推測することができ、ローカルクロックはそうで正しくありません。クロックのRedisはgettimeofdayのではなく、単調を使用考慮すると、システム時刻が影響を受けることになります、急に速くなったり遅くキーで、その結果、前方または後方の期間満了移動させることができます。
目に見える、Redlock時間は多くの仮定に依存し、切れる前に同じRedisのキーが有効期限遅れで、ほとんどの時間を保持している上のすべてのノードが期限切れプロセスは非常に短い休止であると比較して、ネットワークに比べて非常に小さいと仮定することができます。
Redlockを破るために信頼できない時間を持ちます
時間の問題で、信頼できない例をRedlockので、マーティンは、このセクションで引用しました。
CLIENT1 ABCロックへの適用から3つのノード、DE要求は、ネットワーク上の理由に到達しません
クロックノードCの有効期限が切れてロックを生じる、前方に押される
ロックCDEで得られたCLIENT2は、AB要求は、ネットワーク上の理由には届きません
この時点で、CLIENT1とCLIENT2は、ロックを得ています
Redlockでは公式文書にも状況を述べたが、それはCの崩壊までの時間である、Redlockの公式もRedlockアルゴリズム自体は完全に信頼性がないことを知っている、この問題を解決するために、公式には遅延スタートを使用することが推奨され、コンテンツが前にこれを見ることができます記事。しかし、マーティンは遅延がクロックそれの開始の正しさに依存しないことを指摘し、ここではより包括的な分析でしたか？
そして、マーティンは、プロセスの一時停止時間ではなく、クロックが信頼できないときに問題が発生しました引用します：
ABCDEでロックから取得したCLIENT1
ロックがGC休止にCLIENT1 CLIENT1に達していないときに応答が得られた場合
一時停止中にロックを期限切れになりました
ABCDEの中にロックされますCLIENT2
CLIENT1 GCがロックを取得するための完全な応答を受信し、その後、2つのクライアントが同じロックを持っています
長いネットワーク遅延も同様の問題が発生することがありますが。
Redlock同期仮説
これらの例は、システムが以下の性質を満たすことができ、説明あなただけRedlock、上の同期システムモデルの基盤で正しく動作することとします
ネットワーク遅延境界、即ち、データパケットが特定の最大遅延以内に到着できることを仮定
特定における休止の最大期間内境界プロセス、即ちプロセスを停止
NTPサーバからの悪い時間を取得することはありませんバウンダリクロックエラー
結論
マーティンはRedlockは本当にそれがあまりにも重く、高価である分散ロック・アプリケーションの需要のパフォーマンスのために良い選択ではないと考えている。十分なアプリケーションの正しさのためにのために、それは安全ではありません。そのハイリスクのか、上に挙げた他のクロックのため、あなただけの高性能な分散アプリケーションが十分で、ロック・高精度を必要とする単一ノードのRedisていない必要がある場合は、信頼性のない仮定して、あなたの場合それはRedlockをお勧めしませんあなたが残しておきたいアプリケーションの正しさは、我々は、適切な一貫性、例えば、飼育係の座標系、およびフェンシングトークンがあることを確認するための使用をお勧めします。