Redis 分散ロックの原理がまだわかりませんか?早く学んでみませんか？

[[321595]]

学校で小さなプロジェクトに取り組んでいたとき、Redis を使用していましたが、基本的にはキャッシュとして使用されていました。しかし、Ah Fan は仕事中に、Redis が単なる本番環境のキャッシュではないことを発見しました。 Ahfen が関わったプロジェクトでは、Redis は分散ロックの役割を果たしています。具体的な状況は以下のとおりです。

このプロジェクトは金融プラットフォームにおける特定のビジネスを担当します。これは、約 10 個のインスタンスがオンラインで実行される分散システムです。ユーザーが一定の料金を支払う必要があるステップがあり、Redis 分散ロックはおそらくこの位置にあります。

分散ロックが適用された後、システムは 2 つのクエリ検証を実行し、注文レコードをデータベースに挿入し、ロックを解除して支払いプロセスに入ることがわかります。

分散ロックはビジネスの観点からは理解しやすいです。これらは、データのクエリと挿入のプロセス全体の原子性を保証し、クエリの検証中にダーティデータが見つかるのを防ぎ、支払い前に注文情報をテーブルに入れる操作をシリアル化します。

ビジネスの観点からは理解しやすいのですが、Redis を分散ロックとして使用することは私にとっては新しい知識です。プロジェクトのコードに基づいて、この知識ポイントをさらに深く掘り下げる予定です。

文章

1. 分散ロックを使用する理由は何ですか?

実際のプロジェクトで分散ロックを見ると、分散ロックが使用される理由を理解するのは難しくありません。要約すると、分散システムは共有リソースにアクセスする必要があるからです。リソースへの同時アクセスによって発生するエラーを回避するために、共有リソースにロックを追加して各アクセスを相互に排他的にし、同時アクセスのセキュリティを確保します。これが分散ロックを使用する理由です。

2. Redisでの分散ロックの実装

Redis で分散ロックを使用するのは非常に簡単です。キーをロックするには、setnx コマンドを使用します。

 setnx ロックテスト //ロック
del lock test //ロック解除

キーが占有されていない場合、setnx 命令は 1 を返し、そうでない場合は 0 を返します。これが、Redis で分散ロックを使用する原則です。

もちろん、expire コマンドを使用して、ロック後にロックの有効期限を設定することもできます。

これを見て、疑問が湧くかもしれません。プログラム フローがロック解除の命令を使用せず、ロック解除の有効期限の設定に redis を使用する場合、問題が発生すると思われます。 setnx を実行した後、expire コマンドを実行する前にサービス プロセスがクラッシュすると、ロックは解除されません。

はい、確かにこれは問題です。当時、Redis オープンソース コミュニティの人々はこの問題を解決するためのさまざまなソリューションを提案しましたが、実装方法は非常に複雑でした。その後、Redis の作者は、Redis バージョン 2.8 で set コマンドの拡張パラメータを追加し、setnx コマンドと expire コマンドを同時に実行できるようになりました。具体的な使い方は以下のとおりです。

ロックテスト ex 5 nxを設定する
例: キーの有効期限を設定する
nx: キーが存在しない場合にのみ設定します

それ以来、Redis は分散ロックの寵児となりました。

3. Redis クラスターにおける分散ロック

Redis で分散ロックを使用する方法を学習した後、すぐに新たな問題が見つかりました。企業では、Redis は基本的にクラスターで展開されますが、クラスターの展開では必然的にノードのダウンタイムの問題に直面します。

このような状況を考えてみましょう。Redis のマスター ノードに分散ロックを追加するとします。残念ながら、マスター ノードがハングアップし、マスター ノードのロックがスレーブ ノードに同期されていません。この時点でクライアントが同じロックを要求すると、ロックは正常に取得され、以前のロックは完全に無視されます。これは、Redis クラスターの分散ロックで発生する問題です。

この問題を解決するために、Redis の作者は Redlock と呼ばれるアルゴリズムを提案しました。その原理は次のとおりです。ロック時に、set コマンドが半数以上のノードに送信されます。ロックの半分以上が正常に設定されていれば、ロックは成功したとみなされます。ロックを解除すると、del コマンドがすべてのノードに送信されます。

このアルゴリズムの原理から、Redlock は複数のノードを同時に読み書きする必要があるため、Redlock と分散ロックを使用した場合のパフォーマンスは、単一マシンの Redis よりもはるかに低くなることがわかります。マスタースレーブレプリケーションにおけるエラーの確率は極めて低いため、分散ロックプロセスに一定のフォールトトレランスがある場合は、set 命令を直接使用することを検討できます。高可用性を追求する場合は、Redlock アルゴリズムの使用を検討できます。

もちろん、高可用性分散ロックは Redis Redlock に限定されません。分散ロックのトランザクションをサポートする Zookeeper またはデータベースを使用することもできます。

❝Zookeeper の分散ロックの原理を簡単に説明します。zk が特定のノードを分散ロックとして使用すると仮定すると、異なるクライアントが zk 内のロックを競合すると、zk は順番に異なるクライアントの子ノードを作成し、分散ロックとして機能するノードの下にハングアップします。最初に来るクライアントが A、2 番目に来るクライアントが B であると仮定すると、分散ノードの下でハングする最初のノードは A で、次は B となり、B は A の生存状態を監視します。A がロックを解除すると、A は削除されます。このとき、B は A が削除されていることをリッスンし、分散ロックを取得できるようになります。 ❞

同社のプロジェクトでは、Redis はクラスター モードで展開されていますが、分散ロックを取得するために最も基本的なセット命令が依然として使用されています。これは、この方法のパフォーマンスが Redlock アルゴリズムよりもはるかに高く、zk やデータベースなどの分散ロック実装よりも高いためです。

私たちはエラーの確率の低さよりも高いパフォーマンスを選択しましたが、エラー状況をカバーするためにプロジェクト内で他の作業も行いました。たとえば、同社のプロジェクトでは、マスター スレーブ レプリケーション中にエラー状況が発生すると例外がスローされ、その例外に基づいていくつかの再試行操作が実行されます。

要約する

この Redis 分散ロックの調査により、Redis に対する理解が深まりましたが、Redis の用途は分散ロックやキャッシュ以外にも多岐にわたることがわかっているので、後ほど引き続き調査する予定です。