設計レビューの過程で、著者はキャッシュシステムの設計における開発者のいくつかの優れた実践を要約します。
ベストプラクティス1
キャッシュシステムは主にサーバーのメモリを消費します。したがって、キャッシュを使用するときは、最初にアプリケーションがキャッシュする必要があるデータのサイズ（キャッシュデータ構造、キャッシュサイズ、キャッシュ数、キャッシュの有効期限など）を評価し、次にビジネスの状況に応じて評価する必要があります。将来の特定の時間における容量の使用量を計算し、容量評価の結果に基づいてキャッシュリソースを適用および割り当てます。そうしないと、リソースの浪費または不十分なキャッシュスペースが発生します。
ベストプラクティス2
キャッシュを使用するサービスを分離することをお勧めします。コアサービスと非コアサービスは、それらを物理的に分離するために異なるキャッシュインスタンスを使用します。条件がある場合は、サービスごとに別々のインスタンスまたはクラスターを使用して、相互アプリケーションを減らしてください。影響の可能性。一部の企業では共有キャッシュを使用しているため、キャッシュデータが上書きされたり、キャッシュされたデータが文字化けしたりするオンラインインシデントが発生することがよくあります。
ベストプラクティス3
キャッシュインスタンスによって提供されるメモリの量に応じて、アプリケーションが使用する必要のあるキャッシュインスタンスの数がプッシュされます。通常、キャッシュ管理の運用と保守チームが社内に設立されます。このチームは、キャッシュリソースを同じメモリサイズの複数のキャッシュインスタンスに仮想化します。たとえば、インスタンスには4 GBのメモリがあり、アプリケーションを申請するときに使用するのに十分なインスタンスを申請できます。このようなアプリケーションを分割する必要があります。ここで、RDBバックアップメカニズムを使用する場合、各インスタンスは4 GBのメモリを使用します。RDBバックアップはコピーオンライトメカニズムを使用するため、システムは8 GBを超えるメモリを必要とするため、子プロセスをフォークしてコピーする必要があります。メモリのコピーなので、2倍のメモリストレージサイズが必要です。
ベストプラクティス4
キャッシュは通常、データベースの読み取り操作を高速化するために使用されます。通常、キャッシュが最初にアクセスされ、次にデータベースがアクセスされるため、キャッシュのタイムアウト時間の設定は非常に重要です。操作や保守操作のエラーのためにキャッシュタイムアウトが長くなりすぎて、サービススレッドプールが崩壊し、最終的にサービス雪崩が発生したインターネット会社に出会ったことがあります。
ベストプラクティス5
すべてのキャッシュインスタンスで監視を追加する必要があります。これは非常に重要です。遅いクエリ、大きなオブジェクト、メモリ使用量の信頼できる監視を行う必要があります。
ベストプラクティス6
もちろん、複数のサービスがキャッシュインスタンスを共有する場合、この状況はお勧めしませんが、コスト管理のため、この状況が頻繁に発生します。仕様を通じて各アプリケーションで使用されるキーを制限する必要があります。キャッシュの重複の問題を回避するための分離設計。
ベストプラクティス7
キャッシュキーは、キャッシュの有効期限を設定する必要があり、有効期限を特定のポイントに集中させることはできません。そうしないと、キャッシュがメモリまたはキャッシュのペネトレーションを占有します。
ベストプラクティス8
低頻度のアクセスデータをキャッシュに置かないでください。前述したように、キャッシュの主な目的は読み取りパフォーマンスを向上させることです。小規模なパートナーがバッチ処理システムのセットを設計したことがあるので、バッチ処理システムは計算には大きなデータモデルが使用されるため、小さなパートナーはこのデータモデルを各ノードのローカルキャッシュに保存し、メッセージキューを通じて更新されたメッセージを受信して、ローカルキャッシュ内のモデルのリアルタイム性を維持しますが、このモデルは一度しか使用されないため、この方法でキャッシュを使用することは無駄です。これはバッチタスクであるため、最終的な結果を得るには、分割統治の段階的計算方法を使用して、タスクを分割し、バッチ処理を実行する必要があります。
ベストプラクティス9
Redisはシングルスレッドモデルを使用しているため、キャッシュされたデータは、特にRedisが大きすぎることは容易ではありません。単一のキャッシュキーのデータが大きすぎると、他のリクエストの処理がブロックされます。
ベストプラクティス10
より多くの値を格納するキーの場合は、HGETALLなどのコレクション操作を使用しないようにしてください。この操作は、要求をブロックし、他のアプリケーションのアクセスに影響します。
ベストプラクティス11
キャッシュは通常、トレーディングシステムでクエリを高速化するシナリオで使用されます。特にバッチ処理で更新データが大量にある場合は、バッチモードを使用してください。ただし、このシナリオの方が少ないです。
ベストプラクティス12
パフォーマンス要件がそれほど高くない場合は、ローカルキャッシュの代わりに分散キャッシュを使用してみてください。ローカルキャッシュはサービスの各ノード間で複製されるため、このキャッシュが表す場合、特定の時点でコピーが不整合になります。これはスイッチであり、分散システムで要求が繰り返される可能性があります。これにより、繰り返される要求が2つのノードに送られます。1つのノードのスイッチがオンで、1つのノードのスイッチがオフです。要求処理がべき等でない場合、それは処理の重複を引き起こし、深刻な場合には経済的損失を引き起こします。
ベストプラクティス13
キャッシュを書き込むときは、完全に正しいデータを書き込む必要があります。キャッシュデータの一部が有効で一部が無効である場合は、データの一部をキャッシュに書き込むのではなく、キャッシュをあきらめます。そうしないと、nullポインターやプログラム例外などが発生します。
ベストプラクティス14
通常の状況では、読み取りの順序が最初にキャッシュ、次にデータベース、書き込みの順序が最初にデータベース、次にキャッシュの順になります。
ベストプラクティス15
ローカルキャッシュ（Ehcacheなど）を使用する場合、キャッシュオブジェクトの数とライフサイクルを厳密に制御する必要があります。JVMの特性上、キャッシュオブジェクトが多すぎると、JVMのパフォーマンスに大きく影響し、メモリオーバーフローなどの問題が発生します。
ベストプラクティス16
キャッシュを使用する場合、特に重要なビジネスリンクの場合は、ダウングレードプロセスが必要であり、キャッシュに障害があるか無効な場合は、キャッシュをソースに戻して処理する必要があります。