Redis における分散ロック Redlock の分析例

Redlock 実装ライブラリ

• ##Java Redisson Star 9458

• C# RedLock.net Star 259

• Go redsync.go Star 249

背後にあるアルゴリズムは同じですが、「いいね！」の数は本当に印象的です。

シングルポイント Redis ロック

シングルポイント Redis ロックがどのように実装されるかを簡単に確認してみましょう。

ロックの取得

SET resource_name my_random_value NX PX 30000

クライアント A は、Redis を使用してキーと値のペアを設定し、デッドロックを回避するためにタイムアウトを指定します。他のクライアントがアクセスすると、まずキーがすでに存在するかどうか、およびその値が「my_random_value」であるかどうかを確認します。存在する場合は待機します。存在しない場合は成功し、ビジネス コードが実行されます。すべてのクライアントに共有され既知のオブジェクトには、resource_name と my_random_value が含まれます。

ロックを解除

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end

keyで取得した対応する値を比較し、等しいかどうかを確認し、等しい場合は削除(解放)、そうでない場合は削除します。返品失敗。

シングルポイント Redis ロックの欠陥

Redis インスタンスが 1 つしかない場合、障害が発生すると、そのインスタンスに依存するすべてのサービスが崩壊します。この欠陥は非常に重大です。明らか。明らかに大規模なアプリケーションには適していません。

単純な Redis マスター/スレーブ アーキテクチャで遭遇する問題

単一障害点を回避するために、Redis のマスター/スレーブ マスター/スレーブ アーキテクチャを構築します。 1 つのマスター、1 つのスレーブ。以下ではそのような問題に遭遇します。以下に利用シーンを示します。

1. クライアント A がマスターのロックを取得します。

2. このデータをスレーブに同期しているときにマスターがハングアップしました (マスターとスレーブ間の同期が非同期であるため)。

3. スレーブがマスターになります。

4. クライアント B は、同じキーと値を使用してロックを取得します。分散ロックの失敗

Redlock アルゴリズム

N 個 (5 個と仮定) の Redis マスター インスタンスがあり、すべてのノードが互いに独立していると仮定します。システムも単純な通話であり、メッセージの再送信などの補助的なシステムはありません。以下のアルゴリズムをシミュレートしてみましょう:

1. クライアントはサーバーの現在時刻 t0 をミリ秒単位で取得します。

同じキーと値を使用して、5 つのインスタンスでロックを取得します。ビジネス ロックを取得するとき、クライアントはビジネス ロックに必要な時間よりもはるかに短いタイムアウトを設定します。たとえば、ロックに 10 秒かかると仮定すると、タイムアウトを 5 ～ 50 ミリ秒に設定できます。書き直された文: クライアントがロックを取得しようとしたときに Redis が失敗するという状況を回避するには、対策を講じる必要があります。タイムアウト後、次のノードに直接ジャンプします。

3. クライアントは、現在時刻 (t1) から t0 を減算し、ロックを取得するのにかかる時間 t2 (=t1-t0) を計算します。 t2 がロックのビジネス有効時間 (つまり、2 番目のステップでは 10 秒) より短く、クライアントが少なくとも 3 (5/2 1) のプラットフォームでロックを取得した場合にのみ、ロックの取得が成功したと見なされます。 。

4. ロックが取得されている場合、ロックのビジネス有効時間は 10s-t2 です。

5. クライアントがロックを取得しない場合は、N/2 1 以上のインスタンスでロックが取得されていないか、有効時間 (10s-t2) がマイナスである可能性があります。そのノードではロックが取得されていません。

ロックのリリース

リリースは比較的簡単で、すべてのインスタンスの対応するキーを削除するだけです。

以上がRedis における分散ロック Redlock の分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。