Java Web インスタンスの分析

Text

実際の作業プロジェクトでは、キャッシュは高同時実行性と高パフォーマンスのアーキテクチャの重要なコンポーネントとなっていますが、なぜ Redis をキャッシュとして使用できるのでしょうか?まず第一に、キャッシュには 2 つの主な特徴があります。

• 階層化されたシステムでアクセス パフォーマンスの優れたメモリ/CPU に存在すること、

• キャッシュ データが飽和しており、優れたデータ削除メカニズムを備えている

Redis にはこれら 2 つの特性があるため、Redis はメモリ操作に基づいており、完全なデータ削除メカニズムを備えているため、非常に適しています。キャッシュコンポーネントとして。

その中で、メモリ動作に基づいて、容量は32-96GBで、平均動作時間は100nsで、動作効率が高いです。また、データ消去の仕組みも多く、Redis 4.0以降では8種類あり、キャッシュとして多くのシナリオに適用できるようになりました。

それでは、なぜ Redis キャッシュにデータ削除メカニズムが必要なのでしょうか? 8 つのデータ消去メカニズムとは何ですか?

データ削除メカニズム

Redis キャッシュはメモリに基づいて実装されているため、キャッシュ容量には制限があります。キャッシュがいっぱいになった場合、Redis はどのように処理すればよいでしょうか?

Redis キャッシュがいっぱいになった場合、Redis はキャッシュ サービスを再度使用できるように、特定の削除ルールに従って一部のデータを選択して削除するキャッシュ データ削除メカニズムを必要とします。では、Redis はデータを削除するためにどのような削除戦略を使用するのでしょうか?

Redis 4.0 以降は、次の 3 つの主要カテゴリを含む 6 2 の Redis キャッシュ削除戦略があります。

• データ削除なし

• noeviction、データの削除は実行されません。キャッシュがいっぱいになると、Redis はサービスを提供せず、直接エラーを返します。

• 有効期限を設定するキーと値のペアの

• volatile-random のキーで、有効期限を設定します 値のペアから

• volatile-ttl をランダムに削除します。有効期限を設定するキーと値のペアは、有効期限に基づいて削除されます。有効期限が早いほど、 、早く削除されます。

• volatile-lru、LRU (最も最近使用されていない) アルゴリズムに基づいて、有効期限を使用してキーと値のペアをフィルタリングし、最も最近使用されていない原則に基づいてデータをフィルタリングします。

• volatile-lfu は、LFU (Least Frequently Used) アルゴリズムを使用して、有効期限が設定されたキーと値のペアを選択し、最も頻度が低いキーと値のペアを使用してデータをフィルターします。

• すべてのキーと値のペアのうち、

• allkeys-random、すべてのキーと値のペアからランダムに選択され、データを削除します

• #allkeys-lru、LRU アルゴリズムを使用してすべてのデータをフィルタリングします

##allkeys-lfu、LFU アルゴリズムを使用してフィルタリングしますすべてのデータ フィルター

##Note

: LRU (最も最近使用されていない) アルゴリズム。LRU は 2 つのデータを維持します。ウェイ リンク リストリンク リストの先頭と末尾はそれぞれ MRU 端と LRU 端を表し、それぞれ最も最近使用されたデータと最も最近使用頻度が低かったデータを表します。

LRU アルゴリズムを実際に実装する場合、リンク リストを使用してキャッシュされたすべてのデータを管理する必要があり、追加のスペース オーバーヘッドが発生します。さらに、データにアクセスすると、データをリンク リストの MRU に移動する必要があり、大量のデータにアクセスすると、多くのリンク リストの移動操作が発生し、非常に時間がかかり、Redis キャッシュのパフォーマンスが低下します。 。

このうち、LRU と LFU は、Redis のオブジェクト構造である redisObject の lru 属性と refcount 属性に基づいて実装されます。

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    // 对象最后一次被访问的时间
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
    // 引用计数                        * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

Redis の LRU は、redisObject の lru を使用して、最終アクセス時刻を取得し、パラメータ maxmemory-samples で設定された数を候補セットとしてランダムに選択し、その中で lru 属性値が最も小さいデータを選択して除外します。

実際のプロジェクトでは、データ削除メカニズムをどのように選択すればよいでしょうか?

allkeys-lru アルゴリズムを優先して、最後にアクセスしたデータをキャッシュに保持し、アプリケーションのアクセス パフォーマンスを向上させます。

• トップ データは volatile-lru アルゴリズムを使用します。トップ データはキャッシュの有効期限を設定しません。他のデータは有効期限を設定し、LRU ルールに基づいてフィルタリングされます。

• Redis キャッシュ削除メカニズムを理解した後、Redis がキャッシュとしていくつのモードを持っているかを見てみましょう。

Redis キャッシュ モード

Redis キャッシュ モードは、書き込みリクエストを受信するかどうかに基づいて、読み取り専用キャッシュと読み取り/書き込みキャッシュに分類できます。

読み取り専用キャッシュ:読み取り操作のみを処理します。すべての更新操作はデータベース内で実行されるため、データ損失のリスクはありません。

#キャッシュ アサイド モード

##読み取りおよび書き込みキャッシュ、読み取りおよび書き込み操作はキャッシュ内で実行されます。表示 ダウンタイム障害が発生すると、データが失われます。データベースへのライトバック データのキャッシュは、同期と非同期の 2 つのタイプに分類されます。

# 同期: アクセス パフォーマンスが低く、データの信頼性の確保に重点が置かれます

• リードスルー モード

• ライトスルー モード

• 非同期:データ損失のリスク、その焦点は低遅延アクセスを提供することです

• ライトビハインド モード



キャッシュ アサイド モード
クエリまずキャッシュからデータを読み込み、キャッシュに存在しない場合はデータベースからデータを読み込み、データを取得したらキャッシュに更新します。

ただし、データを更新する場合、データはデータベース内のデータが最初に更新され、その後キャッシュされたデータが無効になります。

さらに、キャッシュ アサイド モードには同時実行のリスクがあります: 読み取り操作がキャッシュにヒットしないため、データを取得するためにデータベースがクエリされます。データはクエリされていますが、まだ取得されていません。同時に、更新書き込み操作によってキャッシュが無効になり、その後読み取り操作によってクエリ データがキャッシュにロードされるため、キャッシュされたダーティ データが生成されます。
読み取り/書き込みスルー モード
クエリ データと更新データの両方がキャッシュ サービスに直接アクセスし、

キャッシュ サービスはデータをデータベースに同期的に更新します。ダーティ データの可能性は低いですが、キャッシュに大きく依存しており、キャッシュ サービスの安定性に対する要件がより高くなりますが、同期更新はパフォーマンスの低下につながります。

ライト ビハインド モード
クエリ データと更新データの両方がキャッシュ サービスに直接アクセスします

ただし、キャッシュ サービスは非同期方法を使用して (非同期タスクを通じて) データベースにデータを更新します。 速度 高速で効率は非常に高くなりますが、データの一貫性が比較的低く、データ損失が発生する可能性があり、実装ロジックも比較的複雑です。

実際のプロジェクト開発では、実際のビジネス シナリオの要件に応じてキャッシュ モードが選択されます。上記を理解した後、なぜアプリケーションで Redis キャッシュを使用する必要があるのでしょうか?
アプリケーションで Redis キャッシュを使用すると、システムのパフォーマンスと同時実行性が向上します。これは主に次の点に反映されます。
• 高パフォーマンス: メモリ クエリ、KV 構造、単純な論理演算に基づく

• ##高い同時実行性: Mysql は 1 秒あたり約 2,000 リクエストしかサポートできませんが、Redis は 1 秒あたり 1W を軽く超える可能性があります。クエリの 80% 以上がキャッシュを通過し、クエリの 20% 未満がデータベースを通過できるようにすると、システムのスループットが大幅に向上します

Redis キャッシュを使用すると大幅に向上しますが、キャッシュを使用しないと、キャッシュとデータベース間の双方向の不整合、キャッシュ雪崩などの問題が発生します。これらの問題を解決するにはどうすればよいですか?
キャッシュの使用に関する一般的な問題
キャッシュを使用すると、主に次のような問題が発生します。
• キャッシュは double と一致しません。データベースの書き込み

• キャッシュ雪崩: Redis キャッシュは大量のアプリケーション リクエストを処理できず、データベース層への転送によりデータベース層の負荷が急増します。

• キャッシュ侵入: アクセス Redis キャッシュとデータベースにデータが存在しないため、大量のアクセスがキャッシュを侵入してデータベースに直接転送され、サーバーへの負荷が急増します。データベース層;

• キャッシュの故障: キャッシュが高頻度のホット スポット データを処理できないため、データベースへの直接の高頻度アクセスが発生し、データベース層への圧力が急増します。 ;

キャッシュはデータベース データと矛盾しています

読み取り専用キャッシュ (キャッシュ アサイド モード)

# の場合##読み取り専用キャッシュ (キャッシュ アサイド モード)

、読み取り操作はすべてキャッシュ内で発生し、データの不整合は 削除操作 (新しい操作は発生しません (新しい追加のみが行われるため)削除操作が発生すると、キャッシュはデータを無効としてマークし、データベースを更新します。したがって、データベースの更新とキャッシュ値の削除の処理では、2 つの操作の実行順序に関係なく、どちらかの操作が失敗するとデータの不整合が発生します。

以上がJava Web インスタンスの分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。