nginx proxy_cache キャッシュ設定の詳細な説明

序文：

私は仕事柄、オンラインライブストリーミングの分野に携わっており、ビデオの再生やダウンロードにはビデオダウンロード技術が関わってきます。完全なビデオをダウンロードする場合、現在市場で主流となっているアプローチは、ビデオ ストリーム全体をスライスしてファイル サーバーに保存し、ユーザーが視聴する必要があるときに再生することです。ビデオをソース サーバーに戻すと、ファイル サーバーはビデオを 1 つずつスライスしてユーザーに返すように要求され、再生されます。

今日は、オリジン サーバーのキャッシュの構成と適切なキャッシュ戦略に焦点を当てます。

ソース サーバーのキャッシュを構成するケースを通じて、他のあらゆるキャッシュ構成シナリオに適用できる、完全なキャッシュ構成メカニズムのセットが詳細に説明されます。

本日の説明は4つのポイントに分かれています。

• Back-to-Origin サーバーの役割は何ですか?
• オリジンサーバーにキャッシュを追加する必要がある
• キャッシュの設定方法
• ビジネスシナリオ向けの完全なキャッシュメカニズムを構成する方法
  

元のサーバーに戻る:

以下の説明では、back-to-source サーバーをソース サーバーと呼びます。図に示すように、ファイルのダウンロード プロセス中、ソース サーバーは CDN とファイル サーバーの間に存在し、ダウンロード ハブとして機能します。

ソース ステーション アーキテクチャ: ソース ステーションは、図に示すように、nginx + php の Web サーバー アーキテクチャです。

ただし、オリジン サーバーが単にリクエストを受信し、リソースをダウンロードしてそれを返すだけの場合、次のような最適化されていない問題が必然的に発生します。

1. CDNには複数のソースへの戻り現象が発生する可能性がある

2. ソース ステーションは同じリソースを複数回ダウンロードするため、ネットワーク トラフィックの帯域幅が浪費され、不必要な時間が消費されます。

したがって、これらの問題を最適化するには、ソース サイトにキャッシュ レイヤーが必要です。キャッシュ戦略では、nginx に付属する proxy_cache モジュールを使用します。

Proxy_cache の原則:

proxy_cache モジュールの動作原理を図に示します。

proxy_cacheモジュールの設定方法

nginx.conf ファイルに次のコードを追加します。

http{
  ......
  proxy_cache_path/data/nginx/tmp-test レベル=1:2 キーゾーン=tmp-test:100m 非アクティブ=7d 最大サイズ=1000g;
}

コードの説明:

proxy_cache_path キャッシュファイルパス

レベルはキャッシュファイルのディレクトリ階層を設定します。レベル=1:2は2つのディレクトリレベルを意味します。

keys_zoneはキャッシュ名と共有メモリのサイズを設定します

非アクティブ 指定された時間内に誰もアクセスしない場合は削除されます

max_size 最大キャッシュスペース。キャッシュスペースがいっぱいになると、キャッシュ時間が最も長いリソースがデフォルトで上書きされます。

設定が完了したら、nginx を再起動します。エラーが報告されない場合は、設定された proxy_cache が有効になります。

proxy_cache_path / data / nginx / ディレクトリを確認すると、tmp-test フォルダーが生成されていることがわかります。

proxy_cacheの使い方

対応する nginx vhost サーバー構成ファイルに次のコードを追加します。

場所 /tmp-test/ {
 proxy_cache tmp-テスト;
 プロキシキャッシュの有効性 200 206 304 301 302 10d;
 proxy_cache_key $uri;
 proxy_set_header ホスト $host:$server_port;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_passhttp://127.0.0.1:8081/media_store.php/tmp-test/;
}

設定項目の説明: Proxy_cache tmp-test は、tmp-test という名前の対応するキャッシュ設定を使用します。

proxy_cache_valid 200 206 304 301 302 10d; httpcode 200 を 10 日間キャッシュします

proxy_cache_key $uriはキャッシュの一意のキーを定義し、ハッシュアクセスに一意のキーを使用します。

proxy_set_header は、バックエンドの実サーバーに送信される http ヘッダーをカスタマイズします。

proxy_pass は、プロキシの後に転送されるパスを参照します。最後の / が必要かどうかに注意してください。

この時点で、最も基本的な proxy_cache 関数が正常に構成されました。 URI が場所と正常に一致すると、proxy_cache が有効になります。

proxy_cache を追加すると、リクエスト プロセスが次のように変わります。

1. 初回訪問:

最初のアクセスでは、proxy_cache は対応するキャッシュ ファイルを見つけられませんでした (キャッシュ ミス)。そのため、最初のリクエストが完了すると、proxy_cache はキャッシュを保持します。

2. 図に示すように、キャッシュを保存します。

3. 同じ URL に 2 回目にアクセスすると、同じファイルが元のサイトに再度到着し、proxy_cache は対応するキャッシュ ファイルを見つけ (キャッシュ HIT にヒット)、PHP プログラムを再実行せずにそれを要求元に直接返します (図を参照)。

質問する:

この時点で、最も基本的な proxy_cache 構成とアクセス プロセスの導入は完了しています。ただし、最も基本的な構成ではビジネス ニーズを満たすことができないことがよくあります。次のような質問や要件がよく発生します。

1. キャッシュファイルを積極的にクリーンアップする必要がある
2. 書き込みパスはディスクです。ディスクがいっぱいになった場合はどうすればいいですか?
3. ソースサイトがブレークポイント再開ダウンロードとブレークポイント再開ダウンロードのキャッシュ戦略をサポートできるようにする方法
4. リクエスト終了範囲が同じ URI を持つ大きなリソースをリクエスト (セグメント化されたダウンロード) する場合、リクエストをどのように区別しますか?
5. また、リクエスト者にリソースの有効期限を伝える必要があります。
6. ログ統計: ヒット フィールドとミス フィールドを構成する方法と統計を生成する方法は?

上記の質問に直面して、私たちはそれらを一つずつ解決していきます。

問題1: キャッシュを積極的にクリアする

使用方法: proxy_cache とペアで表​​示され、逆の機能を持つ nginx proxy_cache_purge モジュール。 設計方法: nginx で別のサーバーを起動します。応答リソースのキャッシュをクリーンアップする必要がある場合は、ローカル コンピューターでこのサーバーにアクセスします。 たとえば、リソースのキャッシュ ファイルをクリーンアップするには、127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt にアクセスします。 設定方法:

場所 /tmp-test/ {
        allow 127.0.0.1; //このマシンのみアクセスを許可する deny all; //他のすべてのIPアドレスを許可しない
        proxy_cache_purge tmp-test $uri; //キャッシュをクリーンアップする}

proxy_cache_purge: キャッシュ クリーニング モジュール tmp-test: 指定された key_zone $uri: キーを生成するための指定されたパラメータ proxy_cache_purge キャッシュ クリーニング プロセスは、図に示すように、次のようになります。

質問 2: キャッシュ ファイル ディスクがいっぱいになった場合はどうすればよいですか?

書き込みパスは単一のディレクトリであるため、書き込むことができるのは 1 つのディスクのみです。ディスクがすぐにいっぱいになります。この問題を解決するには 2 つの方法があります。

1. 複数のディスクをディスク アレイに結合するにはどうすればよいでしょうか? 欠点は、実際のストレージスペースが減少することです。

2. proxy_cache_path のディレクトリ構造を巧みに利用します。levels=1:2 なので、キャッシュ ファイルのディレクトリ構造は 2 層になっており、ディレクトリの各層の名前はハッシュ関数によって生成されます。図に示すように:

合計で 16*16*16=4096 個のファイル ディレクトリがあります。図に示すように、第 1 レベルのディレクトリへのソフト リンクを作成し、必要な指定されたディスク ディレクトリへのソフト リンク 0-f を作成します。

ソフト リンク方式により、異なるディスクの下のディレクトリが実際のデータ保存パスとして使用されるようになり、複数のディスクが使用されているのに 1 つのディスクがいっぱいになるという問題が解決されます。

質問3: サポート範囲（ブレークポイント再開）

キャッシュ プロキシを追加すると、次の図に示すように、クライアントによって開始された範囲要求は失敗します。

範囲パラメータを次のレベルに渡すことができない理由は次のとおりです。

キャッシュ プロキシが HTTP 要求をバックエンド サーバーに転送すると、HTTP ヘッダーが変更され、ヘッダー内の一部のパラメーターがキャンセルされます。範囲パラメータがキャンセルされたため、バックエンドの nginx サーバーが範囲パラメータを受信できず、最終的にセグメントのダウンロードが失敗しました。そのため、プロキシ転送ヘッダーを設定する必要があります。 例えば：

場所 /tmp-test/ {
        proxy_cache tmp-テスト;
        プロキシキャッシュの有効性 200 206 304 301 302 10d;
        proxy_cache_key $uri;
        proxy_set_header 範囲 $http_range;
        proxy_pass http://127.0.0.1:8081/media_store.php/tmp-test/;
}

赤い部分の意味: http リクエスト内の範囲値 ($http_range) を、プロキシによって転送される http リクエスト ヘッダーにパラメータ範囲の値として入力します。

質問 4: 範囲読み込みがサポートされている場合、proxy_cache_key を再構成する必要があります。

リクエスト側 Range が同じ URI を持つ大きなリソースをリクエスト (セグメント化されたダウンロード) する場合、プロキシ キャッシュはリソースに対応するキーをどのように識別するのでしょうか? nginx は proxy_cache_key $uri として設定されており、uri をキーとして使用しているため、リクエストが通常のリクエストまたは範囲リクエストの場合、同じ uri がキーとして使用されます。 proxy_cache はおそらくエラーを返します。次の図に示すように:

解決策は次のとおりです: proxy_cache_key を変更し、proxy_cache_key $http_range$uri; を構成します。これにより、キーの一意性が解決されます。これにより、通常のリクエストか異なる範囲のリクエストかを問わず、最初に取得したコンテンツと、その後取得したキャッシュされたコンテンツの異常を防ぐことができます。

質問5: 返品有効期限を設定する方法

リクエスタは有効期限を返すことによって、キャッシュする必要があるリソースとキャッシュしないリソースを指定する必要があります。

要求者がシャードされたリソースを完全なリソースとしてキャッシュするのを防ぐには、通常の要求に対して有効期限を返し、範囲要求に対して有効期限を返さない必要があります。 この問題を解決するには、nginx を次のように設定します。

場所 /media_store.php {
   127.0.0.1:9000; をデフォルトとして設定します。
   fastcgi_index media_store.php;
   fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
   fastcgi_params を含めます。
   $http_range = '' の場合
     2592000秒で期限切れになります。
   }
}

proxy_pass の後の場所に $http_range の判定を追加し、expires で有効期限を指定します。 2592000s はキャッシュの有効期限を示します。

質問7: キャッシュヒットをhttpヘッダーに反映し、nginxログで表示する方法

解決：

nginx $upstream_cache_status 変数の使用: この変数は、キャッシュ ヒットのステータスを表します。

ヒットすればヒット、ミスすればミス

返された nginx サーバー構成を追加します。

Nginx キャッシュに "$upstream_cache_status" というヘッダーを追加します。

nginxlog に追加:

log_format combinedio …$upstream_cache_status;

http リターン ヘッドのスクリーンショット:

nginx ログのスクリーンショット:

要約:

これで、完全なキャッシュ戦略セットの紹介は終わりです。このソリューションは、基本的なキャッシュ構成を実装するだけでなく、ディスク拡張、キャッシュのクリーニング、ブレークポイントの再開、キャッシュの有効期限、キャッシュ ヒットのプロンプトなど、実際のシナリオ アプリケーションで発生する問題も解決します。このソリューションを柔軟に使用する限り、シナリオがいかに複雑であっても、基本的にニーズを満たすことができます。上記は私が仕事で遭遇した落とし穴であり、継続的に改善して結果をまとめたものです。読者の皆様のお役に立てれば幸いです。

nginx proxy_cache の詳細設定に関するこの記事はこれで終わりです。より関連性の高い nginx proxy_cache コンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。