キャッシュに関して最も懸念される問題は何ですか?種類は何ですか？リサイクル戦略とアルゴリズム?

[[342437]]

著者は、正確なタイミング タスクと遅延キュー処理機能を備えた、高同時実行シナリオ向けのシンプルで安定したスケーラブルな遅延メッセージ キュー フレームワークを個人的に開発しました。半年以上前にオープンソース化されて以来、10 社を超える中小企業に正確でタイムリーなスケジューリング ソリューションを提供することに成功し、実稼働環境でのテストにも耐えてきました。より多くの人々の利益のために、オープンソース フレームワークのアドレスが次のように提供されます。

https://github.com/sunshinelyz/mykit-delay

序文

プロジェクトを開始するとき、パフォーマンスの問題をあまり考慮せず、関数をすばやく反復することに重点を置くことがよくあります。ビジネスが急速に発展するにつれて、システムのパフォーマンスはどんどん低下していきます。この時点で、システムはそれに応じて最適化する必要があり、これを実現する最も重要な方法は、システムにキャッシュを追加することです。そこで質問なのですが、システムにキャッシュを追加する場合、キャッシュを使用する際に何に注意すべきか考えたことがありますか?

キャッシュヒット率

キャッシュ ヒット率は、キャッシュからデータが読み取られる回数と総読み取り回数の比率です。ヒット率が高いほど良いといえます。キャッシュヒット率 = キャッシュからの読み取り数 / (合計読み取り数 (キャッシュからの読み取り数 + 低速デバイスからの読み取り数))。これは非常に重要な監視指標です。キャッシュを行う場合は、この指標を監視して、キャッシュが正常に動作しているかどうかを確認する必要があります。

キャッシュタイプ

一般的に、キャッシュの種類は、ヒープ キャッシュ、オフヒープ キャッシュ、ディスク キャッシュ、分散キャッシュに分類できます。

ヒープメモリ

オブジェクトを格納するために Java ヒープ メモリを使用します。ヒープ キャッシュを使用する利点は、シリアル化/デシリアル化がなく、最も高速なキャッシュであることです。デメリットも明らかです。キャッシュされたデータの量が多いと、GC (ガベージ コレクション) の一時停止時間が長くなり、ヒープ領域のサイズによってストレージ容量が制限されます。キャッシュ オブジェクトは通常、ソフト参照/弱参照を通じて保存されます。つまり、ヒープ メモリが不足している場合、この部分のメモリを強制的に再利用してヒープ メモリ領域を解放することができます。ヒープ キャッシュは通常、ホット データを保存するために使用されます。 Guava Cache、Ehcache 3.x、または MapDB を使用して実装できます。

オフヒープメモリ

つまり、キャッシュ データはオフヒープ メモリに保存されるため、GC 一時停止時間を短縮でき (ヒープ オブジェクトがヒープ外に転送され、GC がスキャンして移動するオブジェクトが少なくなります)、より多くのキャッシュ領域をサポートできます (マシン メモリ サイズによってのみ制限され、ヒープ領域の影響を受けません)。ただし、データを読み取る際にはシリアル化/デシリアル化が必要です。したがって、ヒープ キャッシュよりもはるかに遅くなります。これは、Ehcache 3.x または MapDB を使用して実現できます。

ディスクキャッシュ

つまり、キャッシュされたデータはディスクに保存され、JVM を再起動してもデータは存在しますが、ヒープ/オフヒープにキャッシュされたデータは失われ、再ロードする必要があります。これは、Ehcache 3.x または MapDB を使用して実現できます。

分散キャッシュ

分散キャッシュは、ehcache-clustered (Terracotta サーバーを使用) を使用して、Java プロセス間の分散キャッシュを実装できます。 Memcached または Redis を使用して実装することもできます。

分散キャッシュを使用する場合、次の 2 つのモードがあります。

スタンドアロン モード: 最もホットなデータをヒープ キャッシュに保存し、比較的ホットなデータをオフヒープ キャッシュに保存し、それほどホットでないデータをディスク キャッシュに保存します。

クラスター モード: 最もホットなデータをヒープ キャッシュに保存し、比較的ホットなデータを外部キャッシュに保存し、すべてのデータを分散キャッシュに保存します。

キャッシュ削除ポリシー

キャッシュ削除戦略には通常、スペースベースの削除戦略、容量 (スペース) ベースの削除戦略、時間ベースの削除戦略、およびオブジェクト参照ベースの削除戦略が含まれます。

宇宙ベース

スペースベースのキャッシュは、10MB などのストレージ スペースを設定します。ストレージ スペースの制限に達すると、特定の戦略に従ってデータが削除されます。

容量に基づいて

容量ベースとは、キャッシュに最大サイズが設定されていることを意味します。キャッシュされたエントリが最大サイズを超えると、特定の戦略に従って古いデータが削除されます。

時間ベース

TTL (Time To Live): 存続期間は、キャッシュされたデータの作成から有効期限までの期間です (この期間中にアクセスされたかどうかに関係なく、キャッシュされたデータは期限切れになります)。 TTI (Time To Idle): アイドル期間、つまりキャッシュされたデータがアクセスされない期間が長く、その後キャッシュから削除されます。

オブジェクト参照に基づく

ソフト参照: オブジェクトがソフト参照されている場合、JVM ヒープのメモリが不足すると、ガベージ コレクターはこれらのオブジェクトを再利用することができます。ソフト参照はキャッシュに適しているため、JVM ヒープ メモリが不足している場合は、これらのオブジェクトをリサイクルして強参照オブジェクト用のスペースを解放し、OOM を回避できます。弱参照: ガベージ コレクターがメモリを再利用するときに、弱参照が見つかった場合は、すぐに再利用されます。ソフト参照と比較すると、弱参照のライフ サイクルは短くなります。

注: 弱参照/ソフト参照オブジェクトは、他の強参照オブジェクトがそれを参照していない場合にのみ、ガベージ コレクション中に再利用されます。つまり、弱参照/ソフト参照オブジェクトを参照するオブジェクト (弱参照/ソフト参照オブジェクトではない) がある場合、弱参照/ソフト参照オブジェクトはガベージ コレクション中にリサイクルされません。

リサイクルアルゴリズム

スペースベースおよび容量ベースのキャッシュを使用すると、通常は FIFO アルゴリズム、LRU アルゴリズム、LFU アルゴリズムなどの特定の戦略を使用して古いデータを削除します。

FIFO (先入れ先出し): 先入れ先出しアルゴリズム。つまり、キャッシュに最初に入れられたものが最初に削除されます。

LRU (Least Recently Used): 最も最近使用されていないアルゴリズム、現在からの時間距離が最も長いものが削除されます。

LFU (最も使用頻度の低いアルゴリズム): 最も使用頻度の低いアルゴリズム、つまり一定期間内に最も使用回数 (頻度) の少ないアルゴリズムが削除されます。

実際のアプリケーションでは、ほとんどのキャッシュは LRU に基づいています。

この記事はWeChat公式アカウント「Glacier Technology」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Glacier Technology 公式アカウントまでご連絡ください。