除去一開始對所要做的東西的理上的偏差，修改這個key在代碼量上不是很巨大。 cache在nginx中有proxy_cache和memcached，即檔案快取和記憶體快取。檔案快取將訪問過的頁面拷貝到快取檔案中下一次存取根據key如果命中的話直接從快取檔案中讀取而不需要再存取上流伺服器。記憶體快取顧名思義是將檔案快取到記憶體中。
因為對於memcached，一直以來都無法斷到，無法調試，所以就先用proxy_cahce來修改key的生成規則，這個過程中比較有趣的一點是，將key當做字符串後，那這個操作就成了字串操作，對字串操作不存在難以克服的障礙。但需要重視的是cache_key的生成規則在nginx.conf中可以進行配置，所以靈活性很高，並且按照要求，要清除掉key中某幾個字段，這幾個字段也是要寫入配置文件中的，所以del_args這幾個參數的彈性也是非常高的。這麼分析下來，依照硬寫死字串操作將會對後續操作產生不利影響。所以這個規則繼續向下分析。
將這個問題抽像下，從和nginx中緊密相關的細節中抽出要解決的模型，本質上還是個字串處理問題。
字串A，字串的形式與URL的形式很相似，最完整的包括$scheme$domain$uri$is_args$args，這樣的，按照最長的摻水列表進行，隨後的配置表只會比最長的key減少參數。
字元竄B，要從key中刪除的關鍵字，是URL中的參數部分的key， 類似name,age,birth 這樣的，用來清除127.0.0.1/index.html?name=**&age= **中出現過的字符，那就拆分這個，拆分之後再重新組合。
為什麼要這麼費事的把A拆來拆去再重新拼湊？因為讀取的cache_key， 包括ngx_http_request_t中，無論是讀取配置的cache_key,還是這個結構體本身內存在的url，args參數，是定義為ngx_string_t類型，這個類型中的data, 是u_char*類型的，裡面的字串是儲存在全域常數中，只讀，所以在修改的時候，要重新建立新的用來儲存的字串，並且在函數內被操作完賦值給新的Key之後，這個內容還不能消失，所以設定成static，搞成靜態量，儲存位置換成了全域資料區。不過這麼做也會存在一個隱患，設定成static之後，這個值就只會有這麼一個，這次修改之後，賦值給Key, 如果立即使用還好，否則一旦另外的進程或現成修改這個值，那裡面的內容就被替換，但是如果為了防止這種情況對其加鎖，那鎖的開銷就要被考慮進去，綜合起來似乎不如不用static的量，直接在呼叫上層設定一個變量，呼叫生成key的函數在這個作用域內，處理完之後，該變數在堆疊中被處理。
另外一個，就是關於效果展示的，很奇觀竟然需要在前端界面上直接看出是是否命中cache，之所以要求這個，我推測一方面是因為誰都不願意改變自己，尤其是改變自己的習慣，無論這習慣是否奇葩或對自己是否有利或對於自己的技術造詣是否提高，只是習慣罷了；另一方面，如果往好的方面看，應該是要建立監控系統，直接在前端監控伺服器狀態，如果是這個原因，那開發量就會劇增，這個，開發時間就需要繼續往裡加。
總的來說，Nginx設計的模組還算清晰，其中有毛病的地方，改天細說，這玩意寫的時候就跟爬一座巨大的屎山似得，一座搖搖欲墜馬上快要崩潰的屎山。
以上就介紹了關於修改nginx中的cahce的key的生成規則的思考，包括了方面的內容，希望對PHP教程有興趣的朋友有所幫助。
