作者 | 田博文

前言

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

為什么要進(jìn)行性能優(yōu)化？

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

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

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

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

什么是性能優(yōu)化模式？

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

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

請求泛洪與數(shù)據(jù)局部性模式

問題來了！假設(shè)我們自己開發(fā)了一個外賣平臺“餓了美”，為了保證客戶用盡可能少的時間去找商家以提高客戶留存率，我們推出了推薦列表用于推薦用戶可能喜歡的商家或者團(tuán)購，每一個商家都是由多個標(biāo)簽或?qū)傩詷?gòu)成的，這些商家根據(jù)不同的標(biāo)簽或?qū)傩苑植荚诓煌奈⒎?wù)甚至不同服務(wù)器上。此時，要展示推薦列表將會發(fā)生下圖這樣多次請求的情況，即請求泛洪：

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

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

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

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

請求擁塞與水平分割模式

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

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

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

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

降級模式

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

其他模式

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

小結(jié)

性能問題根據(jù)場景不同而千變?nèi)f化，不同場景下其對應(yīng)的性能優(yōu)化模式不同，付出的代價也不同，其歸根結(jié)底還是“看碟下菜”四字。