パート2 キャッシング
前のパートで述べたように、私たちは主にB2Cポータルについて話しています。 これらのポータルには、書き込み要求よりも読み取り要求の優位性という共通の特性があります。 そして、多くの場合、10倍以上の有病率。 キャッシュがそのような有望なツールのように見える理由は明らかです。
キャッシュは興味深い、ほぼ無限のトピックです。 したがって、レベル1およびレベル2のキャッシュ、分散キャッシュなどについては詳しく説明せずに、最初の最適化のために、簡単に概要を説明します。オブジェクトの読み取りをキャッシュする必要があるため、書き込みキャッシュ（書き込みキャッシュ）。
ローカルキャッシュを開始するとき、通常はクエリまたはオブジェクトキャッシュ（呼び出しまたはオブジェクトのキャッシュ）を選択できます。 クエリキャッシュ（またはメソッドキャッシュ）は、「外部」で使用できるキャッシュです。メソッド呼び出し（クエリ）の結果を記録し、同じクエリが同じ答えを引き起こすと仮定します。 同じクエリを複数回繰り返す場合、2回目以降は、複雑で時間のかかる処理をスキップして、前の結果を単純に返すことができます。 このようなキャッシュの利点は、アーキテクチャやドメインに依存しないことです。つまり、ユーティリティ（アスペクトなど）として完成品にあまり変更せずに統合します。 この利点とは対照的に、これらには多くの欠点があります。
- 同じオブジェクトを読み取るためのいくつかのメソッドを持つ豊富なインターフェイスがある場合、それらは無効です。 その理由は、オブジェクト自体ではなく、オブジェクトへのパスをキャッシュするためです。
- そのサイズは、可能なオブジェクト（結果）の数に依存しませんが、可能なクエリの数に依存するため、通常は代替よりも重いです。 それらのサイズと必要なメモリ量を計画するのは困難です。
- 彼らはいです。
オブジェクトキャッシュとは状況が異なります。統合するのは難しくなりますが、はるかに効率的です。 オブジェクトのキャッシュの理想的な実装は、オブジェクト形式でこのサービスによって管理されるすべてのオブジェクトを含むコレクション（リストまたは多くは要件によって異なります）です。 理想的には、サービスは、外部の永続性（データベースなど）に頼ることなく、キャッシュを使用してすべての要求に応答できる必要があります。 残念ながら、このような100％のキャッシュ可能性はめったに達成できませんが、適用できる場合は常に費用対効果が高くなります。 100％キャッシュの最良の例は、ユーザーアカウントです。 通常は小さく（ID、メール、名前、登録時間などで構成されます）、アプリケーションのさまざまな場所で常に必要です。
ないものをキャッシュする
キャッシュのもう1つの有用な形式は、いわゆるゼロキャッシュまたはネガティブキャッシュです。 ほとんどの場合、アプリケーション操作中にオブジェクトキャッシュがいっぱいになるため、いわゆる「コールドスタート」とデータベース内の新しいオブジェクトの作成が可能ですが、同じサービスの複数のインスタンスが同時に存在します。 その結果、アプリケーションへの呼び出しはキャッシュを「突破」してベースに到達する可能性があります。 このような「侵入」が絶えず発生する場合、基地の過負荷につながる可能性があります。 そうすると、そのような難しさで構築されたすべてのキャッシュは、すべての有効性と保護機能を失います。 このような過負荷に対処するため、ポーリングに失敗したオブジェクトを記憶するネガティブキャッシュがあり、それにより、次の要求でサービスに早期に処理を停止する機会を与えます。
変更内容をキャッシュする
キャッシュのもう1つのサブカテゴリはExpiryCachesです。 それらは、オブジェクトまたはそのパーツが一定期間その状態を変更しないという仮定に基づいています。 このようなオブジェクトの典型的な例は、オンラインデートサイトのユーザープロファイルです。 ユーザーAがプロファイルを編集している場合、ユーザーAのプロファイルを表示しているユーザーBの場合、5、30、60秒後にこれらの変更が表示されるかどうかは関係ありません（特にこれらのユーザーが連絡しない場合）。 したがって、ユーザーにとって重要ではないが、マシンの観点から長い間、ユーザーAのプロファイルの状態を修正し、修正済みのバージョンで作業することができます。 これにより、同じ結果を返す可能性が高い（たとえば、メッセージの検索や返信よりもプロファイルの変更頻度がはるかに低いため）多数の要求の処理が防止され、リソースが節約されます。 この節約を支払うことは、私たちができるよりも少し遅れてあなたのプロフィールに更新を表示するリスクです。 この手法は、クライアント側（Webサーバー）で特に人気があり、ネットワークトラフィック（データベースまたはサービスへ）とそれに応じて時間を節約するために使用されます。 ただし、これは有効期限キャッシュの使用が推奨される唯一の例ではありません。 別のユースケースは、リクエストを処理する過程で、同じオブジェクトが何度もリクエストされることを想定していますが、変数内にその値を保存することが不可能または非実用的であるため、コード内で互いに離れている場所からです。 このような中間キャッシュを実装するための一般的な技術は、ThreadLocal（Java）です。
ExpiryCacheは、リソースの交換（トレードオフ）に過ぎません。アプリケーションのパフォーマンスのために、変更の表示速度を犠牲にします。
一般的に、アプリケーション（特にポータル）のスケーリングは、リソースの交換であり、CPU上のRAM、ネットワークトラフィック、またはIOなど、十分ではないリソースに対しては多くのリソースがあります。
キャッシングは、単一のコンポーネントまたはサービスを最適化するための優れた方法ですが、そのような最適化の可能性は限られています。 ある時点で、1つのインスタンスが処理できる限界に達したことを認める必要があり、アーキテクチャのコンポーネントをスケーリングする（つまり、それらの複数のコピーを実行する）必要があります。 これについて-第三部 。