nginxのcahceのキー生成ルールの変更に関する考え

やりたいことの最初の概念的な逸脱を除けば、このキーの変更に膨大な量のコードは必要ありません。 nginx のキャッシュには、ファイル キャッシュとメモリ キャッシュである proxy_cache と memcached が含まれます。ファイル キャッシュは、訪問したページをキャッシュ ファイルにコピーします。次回のアクセスがキーに基づいている場合は、上流のサーバーにアクセスせずにキャッシュ ファイルから直接読み取ります。メモリ キャッシュは、名前が示すように、ファイルをメモリにキャッシュします。

memcached は常に切断してデバッグできないため、最初に proxy_cahce を使用してキー生成ルールを変更しました。このプロセスのさらに興味深い点は、キーを文字列として扱った後、操作が文字列操作になることです。文字列操作にとって、乗り越えられない障害ではありません。ただし、注意が必要なのは、cache_key の生成ルールは nginx.conf で設定できるため、柔軟性が非常に高く、要件に応じてキーの特定のフィールドをクリアする必要があり、これらのフィールドも設定に書き込む必要があることです。ファイルに含まれるため、del_args パラメータの柔軟性も非常に高くなります。この分析に基づくと、ハードコーディングされた文字列操作は後続の操作に悪影響を及ぼす可能性があります。したがって、このルールは下向きに分析を続けます。

この問題を抽象化し、nginx に密接に関係する詳細から解決すべきモデルを抽出します。これは本質的に文字列処理の問題です。

文字列 A、文字列の形式は、URL の形式と非常に似ています。このように、最長の給水リストに従って、その後の構成が含まれます。テーブルは最長のキーよりもパラメータが少ないだけです。

文字B、キーから削除するキーワードは、URLのパラメータ部分のキーで、名前、年齢、生年月日などと同様に、127.0.0.1/index.html?name=**をクリアするために使用されます。 &age= ** に含まれる文字を分割し、再結合します。

なぜAを分解して、また組み立てるのにそんなに苦労しなければならないのですか？ ngx_http_request_t を含むキャッシュ キーは、設定されたキャッシュ キーであっても、構造自体に存在する URL であっても、args パラメーターは ngx_string_t タイプとして定義されているため、このタイプのデータは文字列として保存されます。グローバル定数であり、読み取り専用であるため、変更する場合は、新しい文字列を保存するために再確立する必要があり、この内容は、関数内で操作された後、新しい Key に割り当てられた後は消えることができないため、設定します。 static に変更し、静的数量にして、保管場所をグローバル データ領域に変更します。ただし、これを静的に設定すると、Key に割り当てられる値は 1 つだけになります。 すぐに使用する場合は問題ありませんが、別のプロセスがこの値を変更すると、内部のコンテンツが置き換えられます。ただし、この状況を防ぐためにロックされている場合は、ロックのコストを考慮する必要があります。 , 静的な量を使わずに、呼び出しの上位層に変数を直接設定し、このスコープでキーを生成する関数を呼び出し、処理後に変数をスタック上で処理するのが良いようです。

もう 1 つはエフェクト表示に関するものですが、フロントエンド インターフェイスでキャッシュがヒットしたかどうかを直接確認する必要があるのは奇妙です。これが必要な理由は、誰も変更しようとしないからだと思います。それ自体、特に自分自身の習慣は、それが奇妙であろうとなかろうと、自分にとって有益であったり、技術的スキルを向上させたりするものではありますが、一方で、明るい面に目を向ければ、習慣を確立する必要があります。フロントエンドでサーバーの状態を直接監視する監視システムが必要な場合、開発量は大幅に増加し、開発時間はさらに増加する必要があります。

一般的に、Nginx によって設計されたモジュールには非常に明確な欠陥がありますが、これについてはまた別の機会に説明します。崩壊寸前。

上記では、nginx の cahce のキー生成ルールを変更する際の考え方を、関連する側面も含めて紹介しました。PHP チュートリアルに興味のある友人に役立つことを願っています。