redis を使用するときに注意すべき主な問題は次のとおりです:
redis とデータベースの二重書き込みの整合性の問題 (推奨学習: Redis ビデオ チュートリアル )
分析: 整合性の問題は一般的な分散問題であり、さらに最終整合性と強整合性に分類できます。データベースとキャッシュが二重に書き込まれている場合、必然的に不整合が発生します。この質問に答えるには、まず前提を理解する必要があります。つまり、データに強い整合性要件がある場合、そのデータをキャッシュすることはできません。私たちが行うすべてのことは、最終的な整合性を保証することしかできません。また、根本的に言えば、私たちが作成した解決策は不整合の可能性を減らすことができるだけであり、完全に回避することはできません。したがって、強い整合性要件を持つデータはキャッシュできません。 ----------
分析: 整合性の問題は一般的な分散問題であり、さらに最終整合性と強整合性に分類できます。データベースとキャッシュが二重に書き込まれている場合、必然的に不整合が発生します。この質問に答えるには、まず前提を理解する必要があります。つまり、データに強い整合性要件がある場合、そのデータをキャッシュすることはできません。私たちが行うすべてのことは、最終的な整合性を保証することしかできません。また、根本的に言えば、私たちが作成した解決策は不整合の可能性を減らすことができるだけであり、完全に回避することはできません。したがって、強い整合性要件を持つデータはキャッシュできません。
まず、正しい更新戦略を採用し、最初にデータベースを更新してからキャッシュを削除します。 2つ目は、キャッシュの削除に失敗する問題が発生する可能性があるため、メッセージキューを使用するなどの補償策を提供できることです。
キャッシュペネトレーションとキャッシュアバランシェの問題に対処する方法
分析: 正直に言うと、これら 2 つの問題は、中小企業の伝統的なソフトウェア会社にとって非常に困難です。遭遇したこの問題。大規模な同時プロジェクトがある場合、トラフィックは約数百万になります。この 2 つの問題を深く考慮する必要があります。
回答: 以下に示すように、
キャッシュ侵入、つまり、ハッカーはキャッシュに存在しないデータを意図的にリクエストし、すべてのリクエストがにデータベースに送信され、データベース接続が異常になります。
解決策:
(1) ミューテックス ロックを使用します。キャッシュが失敗した場合は、まずロックを取得してからデータベースを要求します。ロックが取得できない場合は、一定期間スリープして再試行します。
(2) 非同期更新戦略を使用し、キーに値があるかどうかに関係なく直接戻ります。キャッシュの有効期限は値 value に保持されます。キャッシュの有効期限が切れると、スレッドが非同期で開始され、データベースを読み取り、キャッシュを更新します。キャッシュの予熱(プロジェクト開始前にキャッシュをロードする)操作が必要です。
(3) リクエストが有効かどうかを迅速に判断できる傍受メカニズムを提供します。たとえば、ブルーム フィルターを使用して、一連の正当で有効なキーを内部的に維持します。リクエストに含まれるキーが合法かつ有効であるかどうかを迅速に判断します。違法な場合は直接返却してください。
キャッシュ雪崩、つまり広い領域で同時にキャッシュが失敗し、このとき、別のリクエストの波が到来し、その結果、リクエストがすべてデータベースに送信されます。 、その結果、データベース接続が異常になります。
解決策:
(1) 集団的な失敗を避けるために、キャッシュの有効期限にランダムな値を追加します。
(2) ミューテックス ロックを使用しますが、このソリューションのスループットは大幅に低下します。
(3) ダブルバッファリング。キャッシュ A とキャッシュ B の 2 つのキャッシュがあります。キャッシュ A の有効期限は 20 分ですが、キャッシュ B の有効期限はありません。キャッシュのウォームアップ操作は自分で行ってください。次に、以下の点を分解します。
I キャッシュ A からデータベースを読み取り、存在する場合は直接戻ります。
II A にはデータがありません。B からデータを直接読み取り、直接戻ります。 、更新スレッドを非同期的に開始します。
III 更新スレッドは、キャッシュ A とキャッシュ B を同時に更新します。
redis でのキーの同時競合の問題を解決する方法
分析: この問題は、大まかに言うと、複数のサブシステムが同時にキーを設定していることです。このとき私たちは何に注意すべきでしょうか?考えたことはありますか?ブロガーは事前に Baidu を検索し、その答えが基本的に Redis トランザクション メカニズムの使用を推奨していることを発見したことを説明する必要があります。ブロガーは、redis トランザクション メカニズムの使用を推奨していません。本番環境は基本的に Redis クラスター環境であるため、データのシャーディング操作が実行されます。トランザクションに複数のキー操作が含まれる場合、これらの複数のキーは必ずしも同じ redis サーバーに保存されるとは限りません。したがって、redis のトランザクション機構は非常に役に立ちません。
答え: 以下の通りです。
(1) このキーを操作する場合、順序は必要ありません。
この場合、分散ロックを用意し、全員がそのキーをつかみます。 lock の場合は、ロックを取得した後に set 操作を実行するだけで、比較的簡単です。
(2) このキーを操作すると、必要なシーケンスが実行されます。
key1 があり、システム A は key1 を valueA に設定する必要があり、システム B は key1 を valueB に設定する必要があり、システムC は key1 を valueB に設定する必要があります。key1 は valueC に設定されます。
key1 の値は、valueA – > value B – > value C の順序で変化することが予想されます。現時点では、データベースにデータを書き込むときにタイムスタンプを保存する必要があります。タイムスタンプが次のとおりであるとします。
系统A key 1 {valueA 3:00} 系统B key 1 {valueB 3:05} 系统C key 1 {valueC 3:10}
次に、システム B が最初にロックを取得し、key1 を {valueB 3:05} に設定するとします。次に、システム A がロックを取得し、自身の valueA のタイムスタンプがキャッシュ内のタイムスタンプよりも古いことが判明したため、セット操作は実行されません。等々。
Redis 関連の技術記事の詳細については、「Redis データベースの使用に関する入門チュートリアル」 列にアクセスして学習してください。
以上がRedisを使用する際に注意すべき点は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。