Redis での分散ロック実装の詳細な説明
- 小云云オリジナル
- 2017-12-14 14:42:412399ブラウズ
以前に使用したスケジュールされたタスクは 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 です。このような判断を行うのは、ロックされた保持者によるロックを確実に解除するためである。この検証ステップは実行されないと仮定します:
クライアント A がロックを取得し、後続のスレッドがハングします。この時間はロックの有効期限を超えています。
ロックの有効期限が切れると、クライアント B がロックを取得します。
クライアント A が回復した後、関連イベントを処理した後、redis に対して del コマンドを発行します。ロックが解放されました
クライアントCがロックを取得します。現時点では、システム内の 2 つのクライアントが同時にロックを保持します。
この問題の鍵は、クライアント B が保持しているロックがクライアント A によって解放されることです。
操作のアトミック性を確保するには、Lua スクリプトを使用してロックを解放する必要があります。ロックの解除には、get、判定、delの3つのステップが含まれます。 3 つのステップの原子性が保証できない場合、分散ロックには同時実行性の問題が発生します。
上記の詳細に注意を払うと、単一の Redis ノードの分散ロックが実現されます。
この分散ロックにはまだ単一の Redis ポイントが存在します。 Redis はマスター/スレーブ アーキテクチャを採用しているため、障害が発生した場合はスレーブに切り替えるだけだと思われるかもしれませんが、Redis のレプリケーションは非同期です。
クライアント A がマスターのロックを取得した場合。
マスターがスレーブにデータを同期する前に、マスターがダウンします。
クライアント B がスレーブから再びロックを取得しました。
このように、マスターのダウンタイムにより、複数の人が同時にロックを保持することになります。システムが複数の人による短期間のロックの保持を受け入れることができる場合。この簡単な解決策で問題は解決します。
でも、この問題が解決すれば。 Redis は Redlock ソリューションを正式に提供しています。
RedLockの実装
Redisシングルポイントの問題を解決するため。 Redis の作者は RedLock のソリューションを提案しました。計画は非常に巧妙かつ簡潔です。 RedLock の中心的なアイデアは、冗長性のために複数の Redis マスターを同時に使用することであり、これらのノードは完全に独立しており、これらのノード間でデータを同期する必要はありません。
- 現在時刻を取得します
- 上記の方法を使用して、N ノードの Redis ロックを順番に取得します。
- ロックの取得数が(N/2+1)より大きく、取得時間がロックの有効時間(ロック有効時間)未満であれば、有効なロックが取得されたとみなします。ロックの自動解放時間は、最初のロック解放時間から、以前にロックを取得するのに費やした時間を引いた時間です。
- ロックの取得数が(N/2+1)未満の場合、またはロックの有効期限(ロック有効時間)内にロックの取得が不十分な場合は、ロックの取得に失敗したものとみなされます。このとき、ロック解除メッセージをすべてのノードに送信する必要があります。
- 3 つの Redis ノード A、B、C があるとします。
- クライアント foo は 2 つのロック A と B を取得します。
- このとき、Bはダウンし、メモリ内のデータはすべて失われます。
ノード B が応答します。
このとき、クライアントバーはロックを再取得し、2つのノードBとCを取得します。
現時点では、さらに 2 つのクライアントがロックを取得しています。
したがって、回復時間がロックの有効時間よりも長ければ、上記の状況は回避できます。同時に、パフォーマンス要件が高くない場合は、Redis の永続化オプションをオンにすることもできます。
まとめ
Redis の分散実装を理解した後、ほとんどの分散システムの原理は非常に単純ですが、分散システムの信頼性を確保するには、多くの詳細と些細な例外を支払う必要があると実際に感じました。に注意してください。
RedLock アルゴリズムによって実装された分散ロックはシンプルかつ効率的であり、そのアイデアは非常に賢明です。
しかし、RedLock は必ずしも安全なのでしょうか?この問題についても記事を書きます。ご期待ください。
関連する推奨事項:
分散ロックを実装する redisson の方法の原理の詳細な説明
php redis 分散ロックとタスク キューのコード例の詳細な説明
以上がRedis での分散ロック実装の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。