之前已經提過通過 Varnish 緩存進行網站性能優化，以及延遲對商業的影響。
經歷過太多這樣的問題分析和定位過程：

• 某大型網站的 Redis 集群的機器負載每幾十分鐘出現一個超越平時幾十倍大的高峰，結果是因為這些實例每幾十分鐘對所有數據進行寫盤持久化。
• 某大型媒體網站的 MySQL 讀流量異常大，結果是因為每個讀操作都攜帶了 2MB 的頁面初始化信息。這個 BUG 修正的直接結果不僅僅是降低了數據庫的訪問壓力，而且是訪問延遲直接降低了 75%，另外應用服務器的負載也降低很多，節省了服務器。

還有很多類似的故事。

這些故事看起來可笑，但是發生的原因并不可笑。大部分線上系統都會存在類似的問題。

一方面，所有公司都在大量使用開源軟件類庫，某些類庫并不一定針對大流量設計。另一方面，每個運維和開發人員都難以面面俱到。而且，現在互聯網應用越來越復雜，發現問題都非常難。

這種問題自底向上分析是難以避免的，也難以發現，所以應用性能優化需要自頂向下分析，從監控表現入手，尋找線索，進而定位問題。

當然應用整體性能監控、優化，運行成本的降低和把控本身是架構師的主要任務之一。

互聯網應用性能優化 (APO, Application Performance Optimization) 有兩個大的方向可以做：

1. 應用本身的 BUG 和不合理的地方

無論網站還是移動應用 API，或者是實時通訊和聊天系統，本質上都是用戶通過 HTTP 和其他 TCP 協議交互信息的過程。

所以，其中大部分模式都是相通的，并且可以重復利用。比如一些常見的思路和技術：負載均衡、緩存、索引、命名系統、連接重用等等。

隨著流量的變化，引起的延遲變化或者機器負載變化，有經驗的架構師或者運維基本心里有數。通過對商業模式的分析，相對應的在線業務系統應該有的延遲、服務器壓力等等數據可以從心里估算出大致的范圍。結合此業務系統的監控圖表，基本可以很快看出不合理的地方。然后從一個線索入手定位問題所在，進行修復。

2. 應用業務之外的架構層次的修改

假如不考慮程序的 BUG 或者代碼本身的優化，在這之上的一個層次也可以有很多可以優化的方向。

這里主要說明一個利用 最終一致性 的思路修改緩存系統對網頁延遲的優化。

Varnish 4.0 增加了一個新功能：


假如 cache miss，立刻返回給用戶一個之前的舊版本緩存，然后再從應用服務器請求新的版本。這意味著如果緩存足夠大，可以讓用戶 100% 訪問到 Varnish 服務器上緩存的版本，而跳過后端服務器的延遲。這也是為什么標題寫著降低到 0ms :-) 有點標題黨了。

具體的實現方式：
1.保證緩存存儲足夠大
2.保證 Grace 時間足夠長(無限長)
3.假如 obj.ttl + obj.grace > 0s 則返回緩存，否則訪問后端服務器。
這樣離保證用戶 100 % 命中緩存還差一步，就是緩存的預熱。為了避免第一個用戶訪問后端服務器，我們通過主動抓取的方式，或者叫做緩存推送的方式進行緩存的預熱。方式很簡單，逐個向每個 Varnish 實例請求網站的所有 URL。另外，新生成的 URL，首先進行預熱。

需要注意的是，這種方式只適合于用戶對信息新舊不是非常敏感的場景，比如所有的媒體頁面，說明頁面，電商網站的產品說明頁面，移動應用的 Feed API (跳出 Varnish，應用類似思路)。另外，這個方案適用于所有需要針對搜索引擎 SEO 進行延遲優化的場景。

本文轉自：互聯網技術和架構