この記事では、Redis に関する関連知識(shí)を提供し、主にキャッシュの整合性、キャッシュの侵入、キャッシュの破壊、キャッシュなだれ、キャッシュされたデータの書(shū)き込み同期に関連する問(wèn)題を紹介します。 DB の整合性の確認(rèn)。皆様のお役に立てれば幸いです。

関連する推奨事項(xiàng): 「Redis におけるホット キー ストレージの問(wèn)題の分析と、例外をキャッシュするための解決策について語(yǔ)る」

(1) キャッシュ無(wú)効化の一貫性の問(wèn)題

キャッシュの一般的な使用方法は、まずキャッシュを読み取り、キャッシュが存在しない場(chǎng)合は DB から読み取ります。結(jié)果はキャッシュに書(shū)き込まれ、次回データを読み取るときに、データをキャッシュから直接取得できます。 [関連する推奨事項(xiàng): Redis ビデオ チュートリアル ]

データ変更では、キャッシュされたデータを直接無(wú)効にしてから、DB の変更は成功してもキャッシュされたデータが無(wú)効になることを避けるために DB コンテンツを変更します。ネットワークまたはその他の問(wèn)題によりクリアされず、データがダーティになります。ただし、これでもダーティ データの生成を避けることはできません。同時(shí)シナリオの場(chǎng)合: ビジネスでデータ Key:Hello Value:World に対する読み取りおよび変更リクエストが多數(shù)あると仮定します。スレッド A は OCS から Key:Hello を読み取り、Not Found 結(jié)果を取得し、DB からデータの要求を開(kāi)始し、データ Key:Hello Value:World を取得します。次に、このデータを OCS に書(shū)き込む準(zhǔn)備をしますが、OCS に書(shū)き込む前に (ネットワークCPU の待機(jī)により、スレッド A の処理速度が低下する可能性があります。) 別のスレッド B がデータ Key:Hello Value:OCS の変更を要求し、最初に無(wú)効化キャッシュ アクションを?qū)g行します (スレッド B はこのデータが存在するかどうかを知らないため) 、そのため、無(wú)効化操作が直接実行されます) OCS は無(wú)効なリクエストを正常に処理しました。スレッド A に戻って OCS の書(shū)き込みを続行し、Key:Hello Value:World をキャッシュに書(shū)き込みます。スレッド A のタスクは終了し、スレッド B も DB データ コンテンツを Key:Hello Value:OCS に正常に変更しました。この問(wèn)題を解決するために、OCS は Memcached プロトコルを拡張し (パブリック クラウドが間もなくサポートする予定です)、deleteAndIncVersion インターフェイスを追加しました。このインターフェイスは実際にはデータを削除しませんが、データに有効期限が切れたことを示すラベルを付け、データのバージョン番號(hào)を増やします。データが存在しない場(chǎng)合は、NULL が書(shū)き込まれ、ランダムなデータ バージョン番號(hào)も生成されます。 OCS の書(shū)き込みでは、バージョン番號(hào)のアトミックな比較がサポートされています。受信したバージョン番號(hào)が OCS によって保存されたデータのバージョン番號(hào)と一致しているか、元のデータが存在しないと仮定すると、書(shū)き込みが許可されます。そうでない場(chǎng)合は変更が拒否されます。

先ほどのシーンに戻ります: スレッド A は OCS から Key:Hello を読み取り、Not Found 結(jié)果を取得し、DB からデータの要求を開(kāi)始し、データ Key:Hello Value:World を取得して、書(shū)き込みの準(zhǔn)備をします。 OCS このデータ部分のバージョン番號(hào)情報(bào)のデフォルトは 1 です。A が OCS に書(shū)き込む前に、別のスレッド B がデータ Key:Hello Value:OCS を変更するアクションを開(kāi)始します。最初にキャッシュの削除アクションが実行されます。OCS は、キャッシュの削除アクションを正常に処理します。 deleteAndIncVersion リクエストを?qū)g行し、ランダムなバージョン No. 12345 (1000 より大きいことが合意) を生成します。スレッド A に戻り、Key:Hello Value:World の書(shū)き込みを要求して OCS への書(shū)き込みを続けます。この時(shí)點(diǎn)で、キャッシュ システムは、受信したバージョン番號(hào)情報(bào)が一致しない (1! = 12345) ことを検出し、書(shū)き込みは失敗し、スレッド A のタスクが終了します。;スレッド B も DB データ コンテンツを Key:Hello Value:OCS に正常に変更しました。

現(xiàn)時(shí)點(diǎn)では、OCS のデータは Key:Hello Value:NULL バージョン:12345、DB のデータは Key:Hello Value:OCS です。後続の読み取りタスクでは、DB のデータが再試行されます。 OCS に書(shū)き込みます。

(2) キャッシュされたデータの書(shū)き込み同期と DB との整合性の問(wèn)題

Web サイトの規(guī)模が拡大し、信頼性が向上するにつれて、複數(shù)の IDC の導(dǎo)入が課題となります。各 IDC は獨(dú)立した DB およびキャッシュ システムを備えており、キャッシュの一貫性が顕著な問(wèn)題となっています。

まず第一に、高効率を確保するために、キャッシュ システムは BINLOG を書(shū)き込んでいる場(chǎng)合でもディスク IO を防止します。もちろん、パフォーマンス上の理由から、キャッシュ システムは同期削除のみが可能であり、削除はできません。書(shū)き込みは同期的に行われるため、通常はキャッシュ同期が DB 同期の到著よりも優(yōu)先されます (結(jié)局のところ、キャッシュ システムの方がはるかに効率的です)。その場(chǎng)合、キャッシュにデータがなく、DB に古いデータが存在するシナリオが発生します。このとき、業(yè)務(wù)からデータの要求があり、リードキャッシュが見(jiàn)つかりません。DBから読み出してキャッシュにロードした古いデータは古いデータのままです。DBのデータ同期が來(lái)ると、DBのみが更新されます。また、キャッシュされたダーティ データはクリアできません。

上記の狀況からわかるように、不整合の根本原因は、異種システムが連攜して同期できないことです。DB データが最初に同期され、キャッシュされたデータが保証されるわけではありません。後で同期されます。したがって、キャッシュ システムが DB 同期をどのように待機(jī)するか、あるいは 2 つのキャッシュ システムが同期メカニズムを共有できるかを検討する必要があります。キャッシュ同期も DB BINLOG に依存しており、これは実現(xiàn)可能なソリューションです。

IDC1 の DB は、BINLOG を通じて IDC2 の DB に同期されます。この場(chǎng)合、IDC2-DB データ変更により獨(dú)自の BINLOG も生成されます。キャッシュされたデータの同期は、IDC2-DB BINLOG を通じて実行できます。キャッシュ同期モジュールは、BINLOG を分析した後、対応するキャッシュ キーを無(wú)効にし、同期をパラレルからシリアルに変更して順序を保証します。

(3) キャッシュの侵入 (DB に不要なクエリトラフィックが発生)

方法 1: ブルーム フィルターです。これは、要素がセット內(nèi)にあるかどうかを判斷するために使用される、非常にスペース効率の高い確率的アルゴリズムとデータ構(gòu)造です (ハッシュセットと同様)。そのコアは、長(zhǎng)いバイナリ ベクトルと一連のハッシュ関數(shù)です。 Google の guava を使用してブルーム フィルターを?qū)g裝します。 1) 誤計(jì)算率があり、格納する要素?cái)?shù)が増えると誤算率も増加する 2) 通常、ブルームフィルタから要素を削除することはできない 3) 配列の長(zhǎng)さと配列數(shù)を決定するプロセスハッシュ関數(shù)は複雑であり、配布 ロングフィルターの使用シナリオは何ですか? 1) スパム アドレス フィルタリング (アドレスの數(shù)は膨大です) 2) クローラー URL アドレスの重複排除 3) キャッシュの故障の問(wèn)題を解決します

方法 2: 空の結(jié)果を保存し、空の結(jié)果の時(shí)間を設(shè)定します

(4) キャッシュなだれ (キャッシュが同じ有効期限に設(shè)定されているため、DB フラッドが発生します)

方法 1: ほとんどのシステム設(shè)計(jì)者は、単一スレッドを確実にキャッシュするためにロックまたはキューの使用を検討しています。 (プロセス) 失敗時(shí)に基盤(pán)となるストレージ システムに大量の同時(shí)リクエストが発生するのを避けるために書(shū)き込みを行う

方法 2: 失敗時(shí)間のランダムな値

(5) キャッシュの內(nèi)訳 (ホット スポット) キー、多數(shù)の同時(shí)読み取りリクエストによって引き起こされる小さな雪崩)

キャッシュが特定の時(shí)點(diǎn)で期限切れになると、たまたま多數(shù)の同時(shí)読み取りリクエストが発生します。この時(shí)點(diǎn)でのこのキーに対するリクエスト これらのリクエスト キャッシュの有効期限が切れていることが判明した場(chǎng)合、通常、データはバックエンド DB からロードされ、キャッシュにリセットされます。このとき、大量の同時(shí)リクエストにより、瞬時(shí)にシステムが圧倒される可能性があります。バックエンド DB

方法 1: 1. 分散キャッシュを使用する サポートされているミューテックス キーに対してミューテックス キーを設(shè)定し、操作が正常に戻ると、ロード DB 操作が実行され、キャッシュが設(shè)定されます。つまり、DB のロードは 1 つのスレッドによってのみ処理されます。

方法 2: 事前にミューテックス キーを使用する: value 內(nèi)にタイムアウト値 (timeout1) を設(shè)定し、timeout1 が実際の memcache タイムアウト (timeout2) よりも小さいように設(shè)定します。 、ただちにタイムアウト 1 を延長(zhǎng)し、キャッシュにリセットします。次に、データベースからデータをロードしてキャッシュに設(shè)定します。これにより、ビジネス コードの侵入が増加し、コーディングの複雑さが増加します。

方法 3 : 「期限切れにならない」 ": Redis の観點(diǎn)から見(jiàn)ると、実際には有効期限が設(shè)定されていないため、ホットスポット キーの有効期限の問(wèn)題は発生しません。つまり、「物理的」キーの有効期限が切れることはありません。機(jī)能的な観點(diǎn)から見(jiàn)ると、有効期限が切れていない場(chǎng)合は、 , 靜的ではないので、キーに対応する値に有効期限を保存します。有効期限が近づいていることが判明した場(chǎng)合、キャッシュはバックグラウンドの非同期スレッドを通じて構(gòu)築されます。これは「論理的」です。有効期限

(6) キャッシュ システムにおける一般的なキャッシュ フルとデータ損失の問(wèn)題

##特定のビジネス分析に基づく必要があります。通常、オーバーフローを処理するために LRU 戦略を使用します。 、特定の狀況を確実にするための Redis の RDB および AOF 永続化戦略。

プログラミング関連の知識(shí)の詳細(xì)については、

プログラミング ビデオ !! を參照してください。

以上がRedis キャッシュの一貫性、キャッシュの侵入、キャッシュの破壊、キャッシュなだれの問(wèn)題を一緒に分析しましょうの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。