分散ロックを - 学習のRedis

効果を分散ロックをするとき。時計やロックを使用して、異なるRedisのクライアントの間で使用する場合は、システムのパフォーマンスに依存しますキーが頻繁watchコマンドを使用してアクセスされたときに損失が監視するようになります、あなたがする必要がありますロックするかどうかを検討してください。

ロックの設計前にそこにあるかもしれないものの問題について考えてみて

私たちは、最初の使用のロックに発生する可能性のある問題を理解する必要があります。

• ロックにつながったプロセスの動作時間が長すぎるため、ロックを保持しているが、自動的に解除されますが、プロセス自体はロックが解除される知らない、とさえ他のプロセスが保持している、さらに誤っリリースロックを落ちることがあります。

• そして、それは崩壊した演算処理を実行するのに長い時間のためにロックを保持することを意図するが、他のプロセスがロックを保持していることは崩壊したロックを保持しているプロセスを検出することはできませんどのプロセスかわかりません。

• ロックを保持しているプロセスにロックを取得すると同時に、複数のプロセスの後に期限切れになると、ロックが与えられます。

• 複数のプロセスがロックを取得し、あなたがロックを取得だけと思っています。

高同時高負荷の場合には、上記の問題が発生完全に可能であるので、Redisのは、第二100,000の動作は、ハイエンドのハードウェア上で毎秒225,000の操作を行うことができ、最新のハードウェア上で実行することができます。

シンプルなロックv1.0のを設計

正しいロック

使用するsetnxコマンドを、このロックが下図で達成される達成するための前提条件です。获取锁機能：

仕組み：キーが存在しない場合は、そうでない場合は、キーの値を設定し、特定の時間内にしよう。

慎重にリリースロック

ロックされた場合には、使用setnxキーセットUUIDのは、IDは、IDが変わらない場合は、ロックが唯一のロックを解除するために、モニターの時計に使用されている場合、同じIDがロック操作の解放を確保することができます解除することができ繰り返されることはありません繰り返し

以下は、ロックを解除する機能です。

代わりにロックを使用すると、両方の性能比較を見ます

次のコードであるredis in actionだけで分散ロック・デザインの一貫性の問題を達成するために、ここで中古本の場合、達成するために、市場での商品購入での一貫性、：

ロック名があるの内側にこのコードではlock:market、その1つのロックのみではない、あなたはN複数のロックをカスタマイズすることができ、その後、著者は、ビジネスニーズに基づいて性能比較を与えます：

ロックの導入以来、各操作は、実際にある市场オブジェクト実際にロックされていたので、私たちは見ることができ、商品の棚の数にある程度影響を受けることになります以下になりますが、アップグレードの他の側面はまだ非常に明白です。この理由は、加锁的粒度过大市場全体に衝撃が比較的大きくなり、ロックされている。通常、棚が長い、それはあなたが購入するアイテムとは何の関係もないようとしてとき、それはロックされて魚ではありません。

きめ細かいロックV2.0を設計

1.0ロックの改善は、衰退のロックのための競争が、その後、商品の棚に、システム全体のパフォーマンスを向上させるので、ロックの大きさ、商品のみを購入するロックを削減するため、増加します。

きめ細かいロックの比較を使用する場合は、次のように1.0は、次のとおりです。

本は、しばしば、それが実際の状況に応じて決定される、2.0ロックコード、きめ細かいと粗粒選択用のnの複数の性能を示すグラフのみを与えない。必ずしもような細粒度はありません。

V3.0のタイムアウト機能を持つロックデザイン

クラッシュのホルダー。これは、ロックの状態になりますが取得された時には、上記のロックを解除しません。この問題を解決するために、我々は、ロック・タイムアウト機能を追加する必要があります。

タイム・アウト設計は、以下の基本原則に基づいています。

• setnxロックコマンドの割り当て後、ロック追加するために使用することは有効期限が失効します。

• プログラムはsetnxと、ロックを取得しようとしている他のプロセスが、あなたがロックの有効期限までの残り時間を確認する必要があります（極端な場合）有効期限が切れるの間でクラッシュした場合、ロックはあなたが時間を見つけた場合、あなたはロックの有効期限を再度追加する必要があります有効期限はありません。が、そこそこに同時にロックに加える複数のクライアントが時間が期限切れかもしれないが、それは考えることはできないので、それは、大きな違いはありません。

次のコードを最適化した後、ロックを取得する機能です。

注：このコードは比較的古い、新しいRedisのはセットNXで、元サポートオプションは、時間を設定し、そのコードの量がはるかに少ないです。

クライアント側の数はロックの設計は、リソースのV4.0へのアクセスを制限することができます

前世代の機能は、リソースのロックの未来は、ロックのみn番目のプロセスへの彼らのアクセスを許可する、リソースにアクセスするためのクライアント・プロセスによって、このようなロックを設計する能力を保持することができたときにということでロックします。このロックが持っています名前が呼ばれます计数信号量。

技術的には普通のロック、それが失敗した場合にロックを適用し、通常のクライアントとのいくつかのコントラストをセマフォ、それはいくつかの時間が引き続き適用を待ちます。セマフォが失敗したクライアントアプリケーションは、それがリソースを返す場合忙しいの情報が直接です。

この本は、シーンに設計されています。

市場アクセス市場はもはやゲーム内に限定されますが、プロセスは外部の市場にアクセスするために使用することができ、同じアカウントでは唯一の5回のアクセスの最大を処理することはできません。

公正かつ不公平なセマフォセマフォ

ここでは、株式の問題に関連した概念である。本は、設計セマフォが注文したコレクション、IDの順序付きセットのメンバーとして、プロセスIDがスコアの順序集合としてタイムスタンプに追加されますされています、それぞれがプロセスのコレクションを追加した後、自分のランキングを確認する以上5ならば、彼らはセマフォを取得する権利はないことを証明し、あなたがこのセットから自分自身を削除する必要がありますが、問題が発生したとしてタイムスタンプ値を使用して、別のホスト時間が異なる場合があります。

スコアの順序集合として計算アルゴリズムによって不当現象は、通常カウンタと関連して、カウンタ値を回避する。しかし、32ビット・プラットフォームRedisのサーバーのために、カウンタ傾向オーバーフローする。したがって、このため状況は、カウンタの役割は大きくありません。