Redis 分散ロックの進化 過去 2 年間で、マイクロサービスはますます普及し、分散環境に導入されるアプリケーションも増えています。分散環境では、データの一貫性は常に注意を払って解決する必要がある問題です。分散ロックは広く使用される技術になりました。一般的に使用されている分散実装方法は Redis と Zookeeper であり、その中でも Redis に基づく分散ロックが最も広く使用されています。 しかし、私は職場やインターネット上で、Redis 分散ロック実装のさまざまなバージョンを見てきました。それぞれの実装には不正確な点があり、コードも含めて誤った実装である可能性もあります。分散ロックが正しく使用されていない場合、本番環境に重大な障害が発生する可能性があります。この記事では主に、現在遭遇するさまざまな分散ロックとその欠陥をまとめ、適切な Redis 分散ロックを選択する方法についての提案を示します。
さまざまなバージョンのRedis分散ロック バージョン1.0
このバージョンは最もシンプルなバージョンであり、最も頻繁に使用されるバージョンでもあります。まず、ロックに有効期限を追加するのは、アプリケーションの再起動後や例外発生後にロックを解除できない状況を回避するためです。 このソリューションの問題点は、Redis リクエストが送信されるたびに、最初のコマンドの実行後にアプリケーションが失敗したり再起動したりすると、ロックが期限切れにならないことです。改善点の 1 つは、Lua スクリプト (SETNX コマンドと EXPIRE コマンドを含む) を使用することです。ただし、Redis がクラッシュしたり、コマンドを 1 つだけ実行した後にマスターとスレーブの切り替えが発生したりすると、ロックは期限切れにならず、最終的には解放できなくなります。 もう 1 つの問題は、ロックが正常に取得されたかどうかに関係なく、多くの学生が分散ロックを解放するプロセス中に最終的にロックを解放することです。これはロックの誤った使用法です。この問題は、後続のV3.0バージョンで解決される予定です。 ロックが解除されない問題の解決策は、GETSET コマンドに基づいています。 V1.1 GETSETベース
アイデア:
注: このバージョンでは EXPIRE コマンドが削除され、代わりに Value タイムスタンプ値を使用して有効期限を決定します。 質問:
V2.0 SETNXベース
Redis バージョン 2.6.12 以降では、SETNX に有効期限パラメータが追加され、2 つのコマンドがアトミック性を保証できない問題が解決されました。しかし、次のようなシナリオを想像してみてください。
大まかなフローチャート 問題点:
バージョン3.0
このソリューションは、値をタイムスタンプとして指定し、ロックを解除するときにロックの値がロックの値と同じかどうかを確認することで、C1 が C2 によって保持されているロックを解除するというバージョン V2.0 で言及された問題を回避します。さらに、ロックの解放には複数の Redis 操作が含まれ、Check And Set モデルの同時実行性の問題を考慮すると、同時実行性の問題を回避するために Lua スクリプトが使用されます。 問題点:
V3.1
Redis 2.6.12 以降では、SET は SETNX コマンドと同等の NX パラメータも提供します。公式ドキュメントでは、以降のバージョンでは SETNX、SETEX、および PSETEX が削除され、代わりに SET コマンドが使用される可能性があることを通知しています。もう 1 つの最適化は、タイムスタンプの代わりに自己増分する一意の UniqId を使用して、V3.0 で説明されているクロックの問題を回避することです。 このソリューションは現在、最良の分散ロック ソリューションですが、Redis クラスター環境にまだ問題がある場合は、次のようになります。 Redis クラスターのデータ同期は非同期であるため、ロックを取得した後、データ同期が完了する前にマスターノードがクラッシュした場合でも、新しいマスターノードはロックを取得できるため、複数のクライアントが同時にロックを取得できます。 分散 Redis ロック: Redlock バージョン V3.1 は単一インスタンスのシナリオでのみ安全です。海外の分散専門家は、分散 Redis ロックの実装方法について白熱した議論を交わしてきました。 Antirez は分散ロック アルゴリズム Redlock を提案しました。 Redlock の詳細な説明は、distlock トピックで参照できます。以下はRedlockアルゴリズムの中国語の説明です(引用) N個の独立したRedisノードがあると仮定する
しかし、Martin Kleppmann はこのアルゴリズムに疑問を呈し、フェンシング トークン メカニズム (リソースに対するすべての操作にはトークンの検証が必要) に基づくべきだと提案しました。
Redlock の問題への対応として、「Redis に基づく分散ロックは安全か?」という記事が公開されました。詳細な中国語の説明を提供し、Redlock アルゴリズムに存在する問題を分析します。 要約する SETNXバージョンに基づくRedis単一インスタンス分散ロックであっても、Redlock分散ロックであっても、以下の機能を保証する必要があります。 セキュリティ: 複数のクライアントが同時にロックを保持することはできません アクティブ デッドロック: クライアントがクラッシュしたり、ネットワーク パーティションが発生したりした場合でも (通常はタイムアウト メカニズムに基づいて)、最終的にはロックが解除される必要があります。フォールト トレランス: Redis ノードの半分以上が利用可能である限り、ロックを正しく取得および解放できます。したがって、分散ロックを開発または使用する場合、予期しない結果を避けるために安全性とアクティビティを確保する必要があります。 さらに、分散ロックの各バージョンにはいくつかの問題があります。ロックを使用する場合は、ロックの実際のシナリオに応じて適切なロックを選択する必要があります。通常、ロックの使用シナリオは次のとおりです。 効率性: 操作を完了するには 1 つのクライアントのみが必要であり、繰り返し実行する必要はありません。これは緩い分散ロックであり、ロックのアクティビティのみが保証される必要があります。 正確性: 複数のクライアントは厳密な相互排他性を確保する必要があり、ロックを保持したり、同時に同じリソースを操作したりすることはできません。このシナリオでは、ロックの選択と使用をより厳密にし、ビジネス コードをべき等にする必要があります。 Redis 分散ロックの実装には、解決すべき問題がまだ多く残っています。これらの問題を認識し、Redis 分散ロックを正しく実装する方法を理解した上で、作業時に分散ロックを合理的に選択して正しく使用する必要があります。 |
<<: クラウド コンピューティングではなぜ運用と保守が重要なのでしょうか?
深センの天気は相変わらず晴れ。珍しい週末なのでゆっくり休めると思っていたのですが、電話がかかってきて...
ウェブサイトを構築したことがある人なら誰でも、ウェブサイトの開発におけるブランディングの重要性を知っ...
知乎と建書は全く違うようです。最も明らかな違いは、知乎はエリートでいっぱいですが、建書は草の根の執筆...
インターネットに不慣れな起業家の多くは、頭の中に多くの創造的なアイデアを持っているかもしれませんが、...
[51CTO.comからのオリジナル記事] 伝統的なソリューションディストリビューターからデジタルト...
ネットユーザーがインターネットに参入する主要な入り口として、検索エンジンが企業のプロモーションにとっ...
多くの SEO 担当者は、ウェブサイトを構築するときに独自の目的を持っています。おそらく、これらの目...
1月20日、2020年度クラウド管理・クラウドネットワーク優秀事例選定結果が正式に発表されました。今...
事件の原因この事件は、社内の同僚が社内メーリンググループに質問を投稿したことから始まりました。 go...
オフライン展示会の固定観念を打ち破り、移動の手間を省き、疫病下での安全リスクを回避する、新しいオンラ...
Sharktech は、ホスト キャットが評判を上げるたびに「米国で最も耐性のあるサーバー サプライ...
中国最大のリンク交換プラットフォーム「AliVV」の公式サイトが数日連続で開けない状態が続いており、...
インターネットの急速な発展に伴い、ビッグデータの時代が静かに到来しました。しかし、膨大なデータ情報は...
「企業が独自のAIオンラインサービスシステムを構築するのは簡単ではありません。ITインフラストラクチ...
(文/ヘブン)最近、WeChatでインターネットビッグデータに関する記事をよく見かけます。ビッグデー...