Redis での分散ロック実装の詳細な説明

以前に使用したスケジュールされたタスクは 1 台のマシンにのみデプロイされていました。単一点の問題を解決し、タスクが 1 台のマシンでのみ実行されるようにするには、ロックの問題を考慮する必要があるため、時間をかけて調査しました。 。 この問題。分散ロックを実装するにはどうすればよいですか?この記事では、Redis で分散ロックを実装する方法の例を中心に紹介します。参考になれば幸いです。

ロックの本質は相互排他であり、クライアントがいつでも同じロックを保持できるようにするため、redis を使用して分散ロックを実装することを検討している場合、最も簡単な解決策は、インスタンスにキー値を作成し、そのロックを解放することです。ロック時間、キー値を削除します。ただし、信頼性の高い完全な分散ロックを実現するには、多くの詳細を考慮する必要があります。正しい分散ロックの作成方法を見てみましょう。

分散ロック SETNX の単一マシン バージョン

そこで、redis の setNX (SET if Not eXists) コマンドに基づいて単純なロックを直接実装します。疑似コードに直接アクセスします。

ロックの取得:

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 0
 end

注意すべき詳細:

まず、ロックを取得するときにタイムアウトを設定する必要があります。タイムアウトは、ネットワークの問題が発生した後にクライアントがクラッシュしたり、ロックが保持されたりするのを防ぐために設定されます。システム全体がデッドロック状態になっています。

setNX コマンドを使用して、クエリと書き込みステップがアトミックであることを確認します

ロックが解放されると、KEYS[1]) == ARGV[1] と判断されます。ここで、KEYS[1] は redis から取得されます。 ARGV[1] は上で生成された my_random_value です。このような判断を行うのは、ロックされた保持者によるロックを確実に解除するためである。この検証ステップは実行されないと仮定します:

1. クライアント A がロックを取得し、後続のスレッドがハングします。この時間はロックの有効期限を超えています。

2. ロックの有効期限が切れると、クライアント B がロックを取得します。

3. クライアント A が回復した後、関連イベントを処理した後、redis に対して del コマンドを発行します。ロックが解放されました

4. クライアントCがロックを取得します。現時点では、システム内の 2 つのクライアントが同時にロックを保持します。

この問題の鍵は、クライアント B が保持しているロックがクライアント A によって解放されることです。

操作のアトミック性を確保するには、Lua スクリプトを使用してロックを解放する必要があります。ロックの解除には、get、判定、delの3つのステップが含まれます。 3 つのステップの原子性が保証できない場合、分散ロックには同時実行性の問題が発生します。

上記の詳細に注意を払うと、単一の Redis ノードの分散ロックが実現されます。

この分散ロックにはまだ単一の Redis ポイントが存在します。 Redis はマスター/スレーブ アーキテクチャを採用しているため、障害が発生した場合はスレーブに切り替えるだけだと思われるかもしれませんが、Redis のレプリケーションは非同期です。

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

2. マスターがスレーブにデータを同期する前に、マスターがダウンします。

3. クライアント B がスレーブから再びロックを取得しました。

このように、マスターのダウンタイムにより、複数の人が同時にロックを保持することになります。システムが複数の人による短期間のロックの保持を受け入れることができる場合。この簡単な解決策で問題は解決します。

でも、この問題が解決すれば。 Redis は Redlock ソリューションを正式に提供しています。

RedLockの実装

Redisシングルポイントの問題を解決するため。 Redis の作者は RedLock のソリューションを提案しました。計画は非常に巧妙かつ簡潔です。 RedLock の中心的なアイデアは、冗長性のために複数の Redis マスターを同時に使用することであり、これらのノードは完全に独立しており、これらのノード間でデータを同期する必要はありません。

N 個の Redis ノードがあると仮定します。N は 2 より大きい奇数である必要があります。 RedLock 実装手順:

1. 現在時刻を取得します

2. 上記の方法を使用して、N ノードの Redis ロックを順番に取得します。

3. ロックの取得数が(N/2+1)より大きく、取得時間がロックの有効時間(ロック有効時間)未満であれば、有効なロックが取得されたとみなします。ロックの自動解放時間は、最初のロック解放時間から、以前にロックを取得するのに費やした時間を引いた時間です。

4. ロックの取得数が(N/2+1)未満の場合、またはロックの有効期限(ロック有効時間)内にロックの取得が不十分な場合は、ロックの取得に失敗したものとみなされます。このとき、ロック解除メッセージをすべてのノードに送信する必要があります。

ロックを解除する実装は非常に簡単です。以前にロックが正常に取得されたかどうかに関係なく、すべての Redis ノードで解放操作を開始します。

同時に、いくつかの詳細に注意する必要があります:

ロックを取得するための再試行の間隔は、固定時間ではなくランダムな範囲にする必要があります。これにより、複数のクライアントが同時にロック取得操作を Redis クラスターに送信することを防ぎ、同時競合を回避できます。同じ数のロックを同時に取得する状況。 (確率は非常に低いですが)

マスターノードに障害が発生した場合、回復時間の間隔はロックの有効時間よりも長くなければなりません。

1. 3 つの Redis ノード A、B、C があるとします。

2. クライアント foo は 2 つのロック A と B を取得します。

3. このとき、Bはダウンし、メモリ内のデータはすべて失われます。

4. ノード B が応答します。

5. このとき、クライアントバーはロックを再取得し、2つのノードBとCを取得します。

6. 現時点では、さらに 2 つのクライアントがロックを取得しています。

したがって、回復時間がロックの有効時間よりも長ければ、上記の状況は回避できます。同時に、パフォーマンス要件が高くない場合は、Redis の永続化オプションをオンにすることもできます。

まとめ

Redis の分散実装を理解した後、ほとんどの分散システムの原理は非常に単純ですが、分散システムの信頼性を確保するには、多くの詳細と些細な例外を支払う必要があると実際に感じました。に注意してください。

RedLock アルゴリズムによって実装された分散ロックはシンプルかつ効率的であり、そのアイデアは非常に賢明です。

しかし、RedLock は必ずしも安全なのでしょうか?この問題についても記事を書きます。ご期待ください。

関連する推奨事項:

分散ロックを実装する redisson の方法の原理の詳細な説明

php redis 分散ロックとタスク キューのコード例の詳細な説明

分散ロックの複数の実装方法

以上がRedis での分散ロック実装の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。