この記事では、データベースからランダムなエンティティを頻繁にフェッチする場合は Memcache を使用し、REST アーキテクチャを使用する場合は Squid を使用することを主張します。理由を教えてください(イカに関して)。
5 に答える
Memcache は分散オブジェクト ストアです。これにオブジェクトを出し入れするのはあなた次第です。これは、あらゆる用途に使用できる汎用キャッシュです。
Squid はプロキシ サーバーと Web キャッシュです。すべてが URL (REST など) を介して行われる場合、Squid は無料でジョブを実行します。
つまり、memcache は汎用であり、Squid は URL の結果をキャッシュするためのものです。
REST は http とリソースがすべてです。
squid はリバース プロキシとして使用できるため、Web サーバーから負荷がかかります。サーバー側は、キャッシングのタイムウィンドウを示すためにいくつかの有効期限 http ヘッダーを設定できます。
つまり、キャッシングは主に標準の http ヘッダーを介して行われるため、db クエリのキャッシングよりもレスト スタイル アーキテクチャに近いということです。
(この回答は最初の質問から 10 年後に出されますが、私が相談する大規模な組織でこの質問に遭遇したことを考えると、ここで説明することが役立つと思いました。)
Roy FieldingがSOAPを調べたとき、HTTP メソッド(GET、POSTなど) を使用して、単にリモート プロシージャ コールに HTTP を使用するのではなく、リソースにアクセスして変更する場合、HTTP 仕様の残りの部分 (キャッシング ( RFC-2616 ) を利用できます。フィールディングのレイヤード アーキテクチャはこれを示しています。これが彼がRESTを考案した理由です。
HTTP キャッシング プロキシとしてのSquidは、バックエンド システムの負荷を大幅に軽減しながら、キャッシュされたデータが最新であることを確認できる実装です。
この標準では、アイテムが再検証されるまでのキャッシュ期間と条件付きリクエストの作成方法を定義できるため、リクエストに応じて新しいバージョンのみが送信されます。このクライアントの動作はすべて、Java のApache HttpComponents Clientや付随するキャッシング ライブラリなど、主要な言語で使用されるブラウザーや HTTP クライアントに既に実装されています。
これらのメカニズムはすべて明確に定義され実装されているため、これを利用するには、これらのコンポーネントを使用するだけで十分です。これらのコンポーネントのほとんどは既に使用している可能性があります (たとえば、この記事の執筆時点では、Apache HC コンポーネントがデフォルトの実装です)。これは SpringBoot に付属しています - キャッシング ライブラリをビルドに追加するだけです)。
MemCache またはRedisを使用してこれを実装する場合、単に車輪を再発明するだけであり、それ以降そのカスタム コードを維持しなければならないという負担が繰り返されます。また、コードにRFC 2616に相当するものを実装しないと、非効率的な通信で古いデータを使用することになります。
Rest は正しいアクションのために http 動詞を使用します。つまり、GET は常に非破壊的です。URL にも一貫した名前が付けられます。これは、基礎となるプログラミング技術 (ASP MVC、Rails、CouchDB など) に依存することなく、Squid の http キャッシングを使用してパフォーマンスを向上できることを意味します。
Squid (プロキシとキャッシュ) は、REST エンドポイントで効果的に使用できます。REST では、キャッシングを容易にするために、リソースはETAG/Last-Modifiedヘッダーを使用して明示的に転送されます (想定されています)。
さらに、REST の多くの操作は冪等である (と思われる) (それ以上の副作用なしに繰り返す): これは Squid にとって完璧な状況です。アプリケーションサーバーに干渉することなく、これらの操作を単独で実行できます。