Redlock 実装ライブラリ
シングルポイント Redis ロック
シングルポイント Redis ロックがどのように実装されるかを簡単に確認してみましょう。ロックの取得
SET resource_name my_random_value NX PX 30000
ロックを解除
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end
シングルポイント Redis ロックの欠陥
Redis インスタンスが 1 つしかない場合、障害が発生すると、そのインスタンスに依存するすべてのサービスが崩壊します。この欠陥は非常に重大です。明らか。明らかに大規模なアプリケーションには適していません。単純な Redis マスター/スレーブ アーキテクチャで遭遇する問題
単一障害点を回避するために、Redis のマスター/スレーブ マスター/スレーブ アーキテクチャを構築します。 1 つのマスター、1 つのスレーブ。以下ではそのような問題に遭遇します。以下に利用シーンを示します。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 サイトの他の関連記事を参照してください。