相信熟悉 Http 協議的人都瞭解，在 Response Headers 中傳回 Cache-Control 的引數，可以實現客戶端的快取，當然僅僅用客戶端快取，大多數時候其實不能滿足要求，要更好的互動，更快的介面響應，大多數時候會在服務端加入快取。
Nginx Module
這裡以 Nginx ngx_http_fastcgi_module 為例子,具體描述下服務端使用快取的例子。
set $cache_key $request_uri;
fastcgi_cache_path /var/tmp/nginx-cache levels=1:2 keys_zone=cache_zone:64M;
fastcgi_cache cache_zone;
fastcgi_cache_key $cache_key;
fastcgi_cache_lock on;
fastcgi_cache_lock_age 3s;
fastcgi_cache_lock_timeout 3s;本例子是以 reqest_uri 作為 cache key。在服務端接收到相同的 request_uri 的時候，會直接在 ngx_http_fastcgi_module 這個模組中將快取的資料直接 return。
Vary
根據上述使用 request_uri 作為快取的 key，很大程度可以緩解介面效能問題。但是同樣會衍生出一個問題。其實 ngx_http_fastcgi_module 這個模組的快取，會將整個 Response 的全部資訊快取進去，所以能預想到 Response header 的 access-control-allow-origin 這個頭部會別快取成起來，而根據業務邏輯不同，大多數業務系統都只會對 Request 的 Origin 進行單獨簽發。
這種情況下就可能會造成同一個介面，在不同 Host 請求時，某些域名會出現跨域，而且過一段時間後又好了的玄學問題。為了解決這一情況，最快捷的做法是設定 cache_key 字首。即改為：
set $cache_key $http_origin/$request_uri;但是其實快取空間是有限的，我們通過對 cache_zone 的設定為 64M，所以更改 cache_key 的快速解決方案似乎不是最優解。所以這裡在 Response Header 中加入 Vary
Vary: Origin我們在響應的時候，將 Vary 加入響應的頭部，解決了問題。
Nginx Vary 的探究
Vary 很方便地解決了服務端快取 Origin 的問題，但是衍生出一個問題。服務端快取的目的是為了實現更少請求到達業務層，同一個介面下，通過校驗 Origin ，不是當前快取成功的 Origin 會擊穿快取到達業務層，而業務層再對該請求處理，重新包裝 access-control-allow-origin 後重新被 Nginx 快取。周而復始，似乎反而沒有起到該有的快取效果。
為了確認 Vary 方案是否跟上述所想相同，查閱了相關文件。
If the header includes the "Vary" field with the special value "*", such a response will not be cached (1.7.7). If the header includes the "Vary" field with another value, such a response will be cached taking into account the corresponding request header fields (1.7.7).
根據文件,即快取會考慮相應的請求頭欄位，對快取進行管理。那麼其實原理就跟在 cache key 中加入字首是一樣的。
總結
不管是更改 cache key 還是修改利用 Vary 都是實現一樣的效果，且會佔用記憶體。筆者認為在單系統中，兩種方式其實都是可行的，排除掉惡意攻擊，在既定的 origin 情況下，其實記憶體是不會佔用多少，不管是更改 cache key 字首或者使用 Vary。