作者 | 田博文

前言

本文直接從性能優化開始談起，并非意味著尋找性能瓶頸無關緊要，性能優化一般都存在于發現性能瓶頸之后。找到性能瓶頸自然是優化的第一步，畢竟所謂有的放矢。我們今天主要討論的是找到了性能問題之后，到底該怎么辦？

為什么要進行性能優化？

相信大家對這些句子都不陌生：“通過解決了XX提升了30%吞吐量”、“優化了XXX后降低了40%的延遲”等等，可能會有人覺得這么大的性能提升是不是在開玩笑。其實不然，性能優化的效果在早期是相當顯著的，我們先從一個簡單的小例子一窺端倪：

小寅是一位Java開發程序員，他今天的工作是把花果山小賣部的每一筆訂單金額都存到數據庫中并統計合計值。為了盡快完成工作，他把所有訂單都寫入到一個數組中并循環插入到數據庫，他的程序邏輯是這個樣子的：

很明顯，這個邏輯下完成任務總時長等于“幾毫秒×數組數量”，由于平日里花果山沒什么人，小寅的程序提交后一直運行良好，直到有一天，花果山變成了5A級景區……

小寅的代碼在花果山游客大量增加之后延遲過高，已經影響到了其他的業務，而要解決上面的性能問題很簡單，只需要將循環內的insert語句移到循環之外即可。雖然看上去僅改了一行代碼，但這一行的改變中就包含了批處理的解決方案，它減少了與數據庫的交互，與原代碼之間的時間成本天差地別，這就是性能優化帶來的的好處。

什么是性能優化模式？

聊完了性能優化的好處，我們接下來就討論一下什么是性能優化模式，這個說法也是最近看到的一篇博客中提到的：

性能優化模式是一個模型對模型的方式，我們把性能問題想象(抽象)成模型，再把解決它的辦法也抽象成模型，這樣一來就成了惡化模型對應優化模型，而這種組合拳就是性能優化模式，也可以說是解決方案。當然，性能問題千奇百怪，解決方案自然也并非是一成不變，具體問題還得具體分析，我們話不多說，直接開始。

請求泛洪與數據局部性模式

問題來了！假設我們自己開發了一個外賣平臺“餓了美”，為了保證客戶用盡可能少的時間去找商家以提高客戶留存率，我們推出了推薦列表用于推薦用戶可能喜歡的商家或者團購，每一個商家都是由多個標簽或屬性構成的，這些商家根據不同的標簽或屬性分布在不同的微服務甚至不同服務器上。此時，要展示推薦列表將會發生下圖這樣多次請求的情況，即請求泛洪：

我們可以看到，雖然在用戶端只是展現了平臺最推薦的十幾個商家或團購的信息，但是可能背后存在數百甚至數千次的底層服務調用。對于這種存在多次請求問題的分布式系統，請求泛洪所導致的性能惡化幾乎是隨流量呈指數關系增長的。那么可以想像，隨著流量高峰的到來，其需要臨時增加的服務器數量也是指數級的。當然這里有人可能會說，我這個服務是云服務，可以通過一些自動縮放策略來滿足峰時設備需求，比如AWS的Auto Scaling Groups。但是，這只是治標不治本的方案，而且云設備按需付費，設備越多開銷越大，隨著應用越做越大，流量越來越多，這方面的成本將會無限擴大。

這里，我們就要隆重介紹一番針對此問題的解決方案：數據局部性模式。

數據局部性模式擁有一個中心，兩個基本點：一個中心是合理組織數據業務，以減少服務調用次數為中心，兩個基本點是從服務端和客戶端兩點進行優化。在服務端，數據應當由盡可能少的服務器來提供，且常在一起被消費的數據應盡可能放在同一服務器上，如上圖所示。當我們返回給客戶的響應中每一條數據塊都是從數百個服務器上取來拼成的時候，通過木桶效應理論可知，客戶需要等待的時間取決于最慢的那個服務響應的時間。

不僅如此，該模式還解決了依賴的服務器過多造成的系統可用性下降問題，畢竟只要任意一個服務器宕機都會導致整個任務的失敗。在客戶端，我們可以采用本地緩存，批處理請求，一致性哈希左移等方案。一致性哈希左移指的是將需要通過哈希進行負載均衡的服務中的哈希放到客戶端去做，減少服務端的接口調用。說到緩存和批處理，它們帶來的好處是顯而易見的，不只是在各大應用上發光發熱，CPU、操作系統等我們日常接觸的很多東西的設計理念里也少不了它們。當然，事物都有兩面性，這個模式的最大弊端在于它需要進行重構，重構帶來的改變就意味著龐大的工作量以及可能引入的BUG、可靠性問題等。

請求擁塞與水平分割模式

除了可以解決數據泛洪的數據局部性模式，現在讓我們來想象這樣一個場景：我們為某某銀行開發了一個節日福利活動業務，它需要依賴多個服務并依次執行：認證登錄、查詢賬戶過去一個月平均余額、查詢歷史交易信息、查詢用戶福利等級、查詢客戶是否為新用戶等，業務上線后活動極其火爆，參與者眾多，沒過一會兒我們就收到了這樣的反饋：“不行，業務卡死了”、“太慢了”。此時，我們遇到的就是單次請求時延變長導致的系統性能惡化甚至崩潰的情況，即請求擁塞：

用戶想參與福利活動薅點羊毛，但是眾多參與者的加入卻造成了其中某個環節的響應時間變長，在這個系統下，該服務的響應時間上升勢必造成系統整體的響應時間上升，進而出現CPU、內存、Swap報警等一系列問題。自然地，可能很多人就會想到增加服務器的解決方案，既然用戶激增且這樣的狀態并不長久，那么臨時增加服務器分流并進行負載均衡不就行了？這自然也是一個好的解決方案，但我想要介紹的是不需要額外購置服務器的另一個方案：水平分割模式。

水平分割模式就是將整個請求流程切分為必須要相互依賴的多個階段，每個階段包含相互獨立的多種業務處理。完成切分后，該模式按階段內部并行，各階段間串行的方式運作，此時的請求總耗時將下降為各階段間耗時的總和。用上面銀行活動的案例來看，是否使用水平分割模式的效果對比如下(圖中各模塊延遲均為胡謅的)：

并行處理的思路并非萬能，比如在數據更新的時候，并行處理就會出現數據不一致的問題(如下圖)，這也是為什么DB只允許同時只有一個人對一條數據進行更新的原因。另外，還有一種情況，當負載不大時，并行也不會得到很大的性能提升，舉個例子：銀行窗口排隊，如果大廳中沒人等待，那么就算再怎么增加窗口數量，排隊時間也不會有什么優化的余地(因為本就為0)。

降級模式

除了針對性的性能優化模式外，不論任何問題都有一種萬金油式的解決方案：降級模式。降級模式即發生性能惡化時系統進行自我閹割以保證其運轉，常用的降級策略為：流量降級(主動拒絕訪問)、效果降級(使用低質量低延遲服務保證可用性)和功能性降級(取消部分服務保證系統可用性)，用一個情景來說明其區別：計劃公司全體員工去巴厘島度假，但預算不夠。流量降級策略下，只有一半員工去度假了，其余員工僅放假；效果降級策略下，全體員工去北戴河玩；功能性降級策略則是全體員工都去巴厘島，但不提供機票。

其他模式

除上面說到的模式外，在實際場景中還有反貪心模式、緩存思維模式、綁定模式等等。其中，反貪心模式指局部最優并非導向結果最優，比如在頻繁請求的情境下，可能全盤掃描這個看起來并非最優解的方案在整體上會比循環+索引的方案更好；緩存思維模式指頻繁訪問的數據盡可能放在離用戶側較近的位置上，LRU算法、邊緣計算等場景都是應用緩存思維模式的解決方案；綁定模式即在優先考慮局部性的時候，將任務與處理器綁定會更迅速(減少頻繁上下文切換消耗)，此模式典型應用就是多核CPU采用的NUMA(Non-Uniform Memory Access)技術。

小結

性能問題根據場景不同而千變萬化，不同場景下其對應的性能優化模式不同，付出的代價也不同，其歸根結底還是“看碟下菜”四字。