1

HTTP キャッシュ。

HTTP キャッシュはクライアントに送信するためのものか、コンテンツ (ヘッダーではなく本文;) を送信するためのものであると言うのは正しいですか? サーバーとクライアントの間で転送されるデータの数を減らすのに役立ちますが、サーバーの負荷は減りません。HTTP キャッシュはこれを行う必要さえありません。これは問題ではありません。したがって、HTTP キャッシュはサーバー側を気にしません。

したがって、質問です。サーバーの負荷を軽減する最善の方法は何ですか。考えを単純化してください。このコンテンツをクライアントに送信しないのに、なぜ応答用のコンテンツを生成する必要があるのでしょうか。取得したデータがクライアントに送信されない場合、DB に対して重いクエリを実行する必要があるのはなぜですか。はい、リクエストのデータが変更されたかどうかを確認する必要があります。どうにかしてこの情報を保存できるのではないでしょうか? しかし、非常に動的なデータについて話している場合。たとえば、大量の写真を取得するリクエストをキャッシュする必要があり、フィルター (距離別 - 約 1000m、時間別 - 1 時間以内、カテゴリ別など) と並べ替えパラメーター (距離別 - 最も近いもの) を配置できます。クライアントに、時間までに、...）写真に。そして、同じ写真が異なるパラメーターで異なる応答に到達する可能性があります。

4

1 に答える 1

0

リクエストがあります: http://api.myproject/timeline?lat=41.00001&lon=35.80012&category=1&timelimit=60&distance=1000。このリクエストには一意の識別子を作成する必要があります。たとえば、 GET params - request_keyに基づいてこの識別子を作成しています。応答用のデータをフェッチするとき (DB クエリの実行、応答用のデータの準備など)、取得したデータのハッシュを計算する必要があります - data_key. これで、クエリ識別子とデータ キーの 2 つのキーができました。この 2 つのキーとオブジェクト ID を保存します。memcache または redis などの高速ストレージである可能性があります。その後、クライアントに応答を送信し、data_key を含む Etag をヘッダーに入れます。クライアントがデータを取得するために別のリクエストを行う場合、リクエスト キーを生成し、memcache でこのキーの値を見つけようとします。リクエスト キーが見つかり、Etag (hreader から取得) が data_key と一致する場合、このリクエストではデータが変更されていないことがわかり、304 http コードがクライアントに返されます。オブジェクトが変更されると、保存されているすべてのペア request_key と data_key を、このオブジェクトが発生した memcache から削除する必要があります。そのため、オブジェクト ID をペア (request_key、data_key) で保存しています。

于 2012-11-17T10:37:02.637 に答える