本篇關(guān)注程序性能優(yōu)化。聚焦這個主題，本是偶然。始于玩笑，終于本心。本想找點(diǎn)高大上的讓人直呼牛逼的東西，奈何能力有限，只能給大家一些既便宜、又好用、還簡單的普通東西了，不知道你們會不會喜歡。

分為五個主題，分別是『池』『序』『分』『減』『并』：

一、『池』字訣

池化，降低可重用對象的創(chuàng)建和回收代價。

不知道你們發(fā)現(xiàn)沒有，無論是電影還是游戲中，主角總是孤膽單英雄，最多三五成群。但Boss不一樣，Boss手一揮，必須有一群小怪一擁而上，畢竟幫主角刷點(diǎn)經(jīng)驗(yàn)也是好的。

小怪的特點(diǎn)是：數(shù)量多，容易死，循環(huán)用。電影不可能請?zhí)嗟娜貉?，因此我們?jīng)常能發(fā)現(xiàn)一人分飾多角的超級龍?zhí)住６螒蚶?，也不可能每一個小怪都完全不一樣，因?yàn)閯?chuàng)建它們還挺消耗時間和內(nèi)存的。哈哈，現(xiàn)在你知道了，你正在打的小怪很可能與剛剛死前掉金幣的那只是同一只。

代碼中，如果某些對象有重用的價值，并且創(chuàng)建的時候會消耗大量的CPU或IO資源。那么在出現(xiàn)性能瓶頸的時候，一個合理的優(yōu)化方向就是池化。剛剛例子中，對游戲中小怪進(jìn)行池化，通常稱為對象池，類似的還有線程池、連接池等。

灰太狼：我一定會回來的~

二、『序』字訣

順序讀寫，減少隨機(jī)IO，減少cache miss。

『內(nèi)存順序讀寫的性能要遠(yuǎn)好于隨機(jī)讀寫』，『磁盤順序讀寫的性能要遠(yuǎn)好于隨機(jī)讀寫』。類似的話我相信很多程序員都似曾相識，然而，我同樣相信很多程序員在寫代碼的時候從來沒有認(rèn)真考慮過這件事件。

當(dāng)年做游戲的時候，我見過很多人使用hash表存儲場景中的各類對象：花鳥魚蟲、白云蒼狗，并每幀遍歷hash表以確定位置或攻擊信息。我建議他們改成遍歷有序表的快照（MVCC了解一下），其中一個原因是可以提高遍歷性能，而另一個更重要的原因是可以在遍歷的過程中修改表結(jié)構(gòu)（插入刪除對象）。

有序表一種基于有序數(shù)組的字典結(jié)構(gòu)，C#中有一個名為SortList的標(biāo)準(zhǔn)庫實(shí)現(xiàn)

多年以來，CPU一直是計算機(jī)中跑得最快的部件，也因此被慣出來一個多吃多占的毛病。無論是讀內(nèi)存還是讀磁盤，從來不講究按需分配，而是大塊大塊的拿數(shù)據(jù)。當(dāng)把一大塊連續(xù)的數(shù)據(jù)拿到手里的時候，CPU自己也知道一次肯定吞不下，但總覺得多吞幾次就好了。

但這個特點(diǎn)其實(shí)是需要程序員去配合的，如果代碼使用連續(xù)內(nèi)存的數(shù)據(jù)結(jié)構(gòu)，比如array，那在遍歷的時候就相當(dāng)于投其所好；而如果代碼使用hash表，則遍歷的時候cache miss的可能性就大大增加。

鑒于java在服務(wù)器領(lǐng)域的成功，有些公司使用java開發(fā)游戲服務(wù)器，我建議他們換一種語言。原因是游戲服務(wù)器很可能需要處理大量跟點(diǎn)、向量等三維空間相關(guān)的運(yùn)算，而在java中，默認(rèn)一切都是對象。于是在一個Vertex（頂點(diǎn)）數(shù)組中，看似連續(xù)的Vertex對象在物理內(nèi)存中實(shí)際上是離散的，這樣的遍歷效果就會差很多。而對C++, Golang，甚至C#這類語言來說，它們都支持struct。當(dāng)把Vertex定義為struct的時候，一個Vertex數(shù)組的占用的內(nèi)存就是連續(xù)的，遍歷效果會比java好很多。

在后端的技術(shù)棧中，kafka絕對是一個非常另類的存在。擅長kafka的人，覺得無它不歡，而不了解它的人，則覺得可有可無。關(guān)于kafka為什么這么快的討論有很多，其中有一個繞不過的原因是：kafka會順序讀寫磁盤。我們通常認(rèn)為磁盤的讀寫性能遠(yuǎn)低于內(nèi)存，但實(shí)際上，在關(guān)閉fsync的前提下，SSD固態(tài)硬盤的順序讀寫速度與內(nèi)存的隨機(jī)讀寫速度是相當(dāng)?shù)模蟾哦际? GiB/s，而如果是隨機(jī)讀取，則SSD固態(tài)硬盤SSD的Seek速度會直降到70MiB/s，速度下降到1/15。

三、『分』字訣

鴻蒙伊始，民智不開。為教化萬民，神器計算機(jī)降世。下凡走得急，零件沒湊齊。計算機(jī)天生殘疾，CPU與其它IO部件速度差異過大。為平衡這種速度差異，人間有智者布局各方，分字訣應(yīng)劫而生，它們是分批、分幀、分頁、分時、分片、分區(qū)、分庫、分表、分離。

1. 分批≈緩存+緩沖

在系統(tǒng)設(shè)計之初，每次修改對應(yīng)一次IO可能是最簡單、最直接的設(shè)計，不過隨著系統(tǒng)流量變大，IO可能會很快成為系統(tǒng)瓶頸。相比于內(nèi)存操作來說，磁盤IO吞吐小，網(wǎng)絡(luò)IO延遲大。為了減少IO與內(nèi)存之間的速度差異，爭取每次IO都物盡其用才是上上之選。將多次IO合并為一次，減少磁盤IO（特別是fsync）的次數(shù)和網(wǎng)絡(luò)IO的round-trip次數(shù)。

所謂讀優(yōu)化靠緩存，寫優(yōu)化靠緩沖，而分批≈緩存+緩沖。往小了說，緩存就是一塊用于讀內(nèi)存，緩沖就是一塊用于寫的內(nèi)存。往大了說，緩存就是Redis，緩沖就是Kafka。這些都是在微服務(wù)體系中司空見慣的招數(shù)，不用我多說。

分批優(yōu)化化身千萬，可謂無孔不入，甚至多數(shù)流行的數(shù)據(jù)中間件都提供了批量IO操作的API：

• MySQL的insert語句支持在values中一次插入多行數(shù)據(jù)。
• Redis的Pipeline操作可以批量執(zhí)行多個操作。
• ElasticSearch有專門的_bulk api支持在單次調(diào)用中索引或刪除多條數(shù)據(jù)。
• Kafka更是把分批操作貫徹到了極致：它根本就不提供發(fā)送單條消息的功能，使用send()發(fā)送的單條消息其實(shí)會被Kafka偷偷在內(nèi)存里攢起來，是的你被騙了。
• 包括MySQL, Redis在內(nèi)的各類數(shù)據(jù)中間件，跟WAL日志落盤時機(jī)相關(guān)的配置中，一定有一條是只寫Page Cache，然后后臺線程定期刷盤的策略。（注：嚴(yán)格說來，Redis那個不能叫WAL，因?yàn)樗菍懞笕罩尽＃?/li>
• 在游戲引擎中，把頂點(diǎn)數(shù)據(jù)提交的顯卡的Draw Call也都是合并批次的，否則會卡死你。

分批的缺點(diǎn)是在數(shù)據(jù)一致性差，無論是緩存還是緩沖都存在同樣的問題。緩存的話，如果不存在嚴(yán)格的一致保障手段，往往只建議展示用，不作為數(shù)據(jù)修改依據(jù)。參考文章《緩存就像showgirl，看看就行了》。而緩沖在內(nèi)存的這段時間內(nèi)，如果進(jìn)程崩潰了，會丟失部分?jǐn)?shù)據(jù)。因此在選擇分批優(yōu)化的時候，架構(gòu)師需要仔細(xì)斟酌數(shù)據(jù)一致性問題，比如是否可以接受偶爾丟失數(shù)據(jù)，或者是否需要在數(shù)據(jù)輸入端提供重試策略。

但不管如何，分批都可能是最重要的IO優(yōu)化手段：它邏輯簡單，不涉及多線程并發(fā)，對數(shù)據(jù)結(jié)構(gòu)沒有特殊的要求，系統(tǒng)改造成本低?？梢哉f，無論何時遇到IO性能瓶頸，分批改造都應(yīng)該是順位第一的候選方案。

2. 分幀、分頁、分時

1）分幀，是專用于單線程+阻塞IO的平滑技術(shù)

很多時候，由于受框架限制（比如游戲或網(wǎng)頁渲染），我們不得不在單一線程中同時處理用戶邏輯與IO操作，這時如果IO消耗時間過長，就會阻塞用戶邏輯代碼，從而讓用戶感覺到卡頓現(xiàn)象。

Redis由于其單線程特性，很多耗時比較長的操作也需要分?jǐn)偟蕉鄮瑘?zhí)行。比如hash表的rehash操作，當(dāng)表的鍵值對過多時，rehash會產(chǎn)生的龐大的計算量，如果一次性完成可能會導(dǎo)致server對外暫停服務(wù)。Redis選擇將rehash分?jǐn)偟蕉啻螆?zhí)行，稱為漸進(jìn)式rehash。

另外，對于比較大的hash表，hgetall一次性獲取所有數(shù)據(jù)可能會卡死server進(jìn)程甚至導(dǎo)致宕機(jī)，建議采用hscan來分次獲取hash表中的數(shù)據(jù)。Redis中像這類支持迭代式掃描的命令有四個，分別是：scan, sscan, hscan和zscan。

2）分頁可以看作是一種另類的分幀操作：

在運(yùn)營類項(xiàng)目中，由于后臺數(shù)據(jù)龐大，很多時候無法在單一網(wǎng)頁中顯示，通過分頁顯示，可以避免一次性數(shù)據(jù)獲取帶來的DB加載壓力和網(wǎng)絡(luò)傳輸壓力。

3）分時復(fù)用指多對象輪流使用同一個硬件的技術(shù)，多見于跟硬件打交道的底層軟件。

比如，分時操作系統(tǒng)：一種采用時間片輪轉(zhuǎn)的方式同時為幾個甚至幾百個用戶服務(wù)的操作系統(tǒng)；分時復(fù)用網(wǎng)絡(luò)：指采用同一物理連接的不同時段來傳輸不同的信號，以達(dá)到多路傳輸目的的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。

但有一種分時復(fù)用技術(shù)，雖然它的名字里沒有分時二字，卻與后端開發(fā)息息相關(guān)，那就是IO多路復(fù)用（洋名：Reactor）：單線程同時監(jiān)聽多個文件句柄，哪個句柄就緒，就通知應(yīng)用線程讀寫哪個句柄的技術(shù)。

3. 分片、分區(qū)、分庫、分表

隨著77年恢復(fù)高考，這些年近視的年輕人越來越多了，于是人們越發(fā)的無法區(qū)分那些換個馬夾兒就重新出來混的二貨們。就像洗發(fā)水，猛一看飄柔、海飛絲、潘婷百花齊放，仔細(xì)一看，全特么是寶潔的。沒錯，這么土味的名字，竟然不是國貨，害我自以為愛了這么多年的國。

分片、分區(qū)、分庫、分表也一樣，名字挺花，療效一樣，都是為了突破單體性能限制的水平擴(kuò)展的方案，洋名字：scale out。因?yàn)榉桨割愃疲蠹矣龅降膯栴}自然也是相同的。它們首先要搞定的就是路由問題，也就是把數(shù)據(jù)拆分之后，某個key儲存到哪個分片/區(qū)/庫/表的問題。路由方案可簡單分為兩類：

一種是非確定性路由，即相同的key多次路由可以映射到的不同的計算單元，常見方案有：輪詢、隨機(jī)。非確定性路由多用于無狀態(tài)節(jié)點(diǎn)間的任務(wù)分配，比如nginx把請求隨機(jī)分配到無狀態(tài)的微服務(wù)節(jié)點(diǎn)上。

另一種是確定性路由，即相同的key多次路由必須映射到的相同的存儲單元，常見方案為：區(qū)間，Hash，配置表。確定性路由多用于有狀態(tài)節(jié)點(diǎn)間的任務(wù)分配，比如Kafka按user_id把來自同一用戶的請求映射到同一個存儲分區(qū)。

以MySQL為例，它支持四種分區(qū)類型，分別是Range, List, Hash, Key。因?yàn)楦鎯γ芮邢嚓P(guān)，它們?nèi)谴_定性路由算法，其中Range對應(yīng)區(qū)間，List是配置表，Hash與Key則都是Hash類型。

除了應(yīng)用于多機(jī)水平擴(kuò)展，在單機(jī)內(nèi)存中分片方案也有應(yīng)用。比如JDK1.8之前，ConcurrentHashMap通過將整個Map劃分成N（默認(rèn)16個）個Segment，而每個Segment各自持有獨(dú)立的鎖，從而從整體上減少并發(fā)沖突。

4. 分離

分離式設(shè)計是一種架構(gòu)模式，通過把單元功能單一化、純粹化、專業(yè)化，可以降低開發(fā)和維護(hù)成本，同時提高功能單元的可復(fù)用性，這在設(shè)計模式中我們通常稱之為單一職責(zé)。目前，常見的分離式架構(gòu)設(shè)計有讀寫分離、存算分離。

讀寫分離在國人的文章中常用于指代MySQL寫走主庫，而讀走從庫，這有些狹義了。廣義上讀寫分離的重點(diǎn)是：讀路徑不關(guān)心寫，寫路徑不關(guān)心讀，兩者均關(guān)注于自己的功能實(shí)現(xiàn)，而毋需為對方的作出任何犧牲或讓步。更多的細(xì)節(jié)我在文章《23.kafka心中的事件溯源》中有更詳細(xì)的描述，感興趣的讀者可以點(diǎn)擊查看。

這里我想強(qiáng)調(diào)的是，讀寫分離是分離式DB（Unbunding Databases）的雛形。我們應(yīng)該認(rèn)識到，不存在一種單一的數(shù)據(jù)模型可以滿足所有的訪問模式。MySQL在線業(yè)務(wù)、Redis加速查詢、ES全文索引、DW離線分析，每一種衍生數(shù)據(jù)系統(tǒng)都有各自不可替代作用。

如上圖所示，通過統(tǒng)一寫端，派生讀端，可以形成一種遵循unix傳統(tǒng)的架構(gòu)模型：單一任務(wù)做好單一事情，內(nèi)部通過低級API（pipe）通信，外部通過高級語言（shell）組合。在分離式DB架構(gòu)中，目前看來最合適的，能起到粘接劑作用的是Event Stream（Event Log）。期望未來有那么一天，我們能像在shell中寫ps | grep java一樣，寫出mysql | elasticsearch這樣的代碼，屆時就是分離式DB摘取王之桂冠的榮耀時刻。

如果說讀寫分離是拆功能，那么存算分離就是拆資源：把計算資源（CPU、內(nèi)存）和存儲資源（磁盤）拆分開來。早期的云DB，其實(shí)是把單體DB搬到云上。人們很快發(fā)現(xiàn)云DB與單機(jī)DB的不同之處：一是隨著企業(yè)數(shù)字化轉(zhuǎn)型的深入，數(shù)量總量飆升，單機(jī)存儲捉襟見肘；二是在應(yīng)對雙十一這類突發(fā)性流量時，計算峰值波動很大，這使得云DB對彈性伸縮能力要求極高。問題一可以通過分庫分表這類trick的方式緩解，但問題二對原有單體DB『存算一體』的架構(gòu)提出了挑戰(zhàn)。于是，存算分離的架構(gòu)應(yīng)運(yùn)而生，也就是云原生數(shù)據(jù)庫架構(gòu)。

存算分離聽起來很云端，似乎跟我們平時的工作關(guān)系很小。但其實(shí)有一類架構(gòu)它就在我們身邊，只是我們可能沒有意識到它也是存算分離架構(gòu)，那就是微服務(wù)架構(gòu)。計算節(jié)點(diǎn)無狀態(tài)，存儲節(jié)點(diǎn)無計算；計算節(jié)點(diǎn)橫向擴(kuò)展，存儲節(jié)點(diǎn)縱向擴(kuò)展。

就像Duck Test講的：如果它看起來像鴨子、游泳像鴨子、叫聲像鴨子，那么它可能就是只鴨子。

四、『減』字訣

很多時候我們都講不要過早優(yōu)化，因?yàn)槎鄶?shù)業(yè)務(wù)的初期，數(shù)據(jù)量都很少，任何設(shè)計都不太可能出現(xiàn)性能問題。反而業(yè)務(wù)上線后，由于進(jìn)展不符合預(yù)期，導(dǎo)致調(diào)整業(yè)務(wù)邏輯的可能性更大。因此，怎么簡單怎么來才是最優(yōu)選擇，更快的實(shí)現(xiàn)業(yè)務(wù)比業(yè)務(wù)跑得更快優(yōu)先級更高。再者，你難道不覺得，就憑咱們拿的那萬兒八千的工資，在非常合理的情況下，就不應(yīng)該寫出支撐千萬并發(fā)的系統(tǒng)，嘛？

萬一哪天系統(tǒng)開始出現(xiàn)性能瓶頸呢？該怎么辦？恭喜哈，這是好事，說明公司賺錢了，更重要是通過你的系統(tǒng)賺錢了。首先，你要做的第一件事就是跟老板要經(jīng)費(fèi)，經(jīng)費(fèi)到手，萬事不愁。然后，想辦法把系統(tǒng)恢復(fù)到數(shù)據(jù)量小的時候，這不就又順理成章的撐住了嘛？接著，經(jīng)費(fèi)沒地方花了不是？總得找個地方放啊，我私下認(rèn)為你的錢包就是一個不錯的地方。

怎么把數(shù)據(jù)量再次變小呢？勸退用戶是一個辦法，但我估計老板可能太不樂意。

一個更可行的選擇是優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法。比如給DB建索引就是一個辦法，同樣的查詢，同樣是千萬級的數(shù)據(jù)，有索引和無索引的查詢速度千差萬別，因?yàn)樗饕龝O大減少掃描的數(shù)據(jù)行數(shù)。

另一個選擇是裁剪數(shù)據(jù)。就像Java的GC會定期清理垃圾一樣，如果你發(fā)現(xiàn)DB里的數(shù)據(jù)大部分都是過期無效的，或者是基本上不會再查詢到的數(shù)據(jù)，把過期數(shù)據(jù)歸檔，減少線上數(shù)據(jù)集的尺寸會是一個非常好的選擇。該操作系統(tǒng)改造成本極低，對線上業(yè)務(wù)無影響，對數(shù)據(jù)后臺則可以看心情逐步改造。所有相關(guān)人員都壓力不大，但效果卻是線上系統(tǒng)從此秒開，絕對騷得一批。其實(shí)前面提到的分片、分區(qū)、分庫、分表，也都是在變相減小單位處理單元上的數(shù)據(jù)量，只不過它們改造成本高，實(shí)施難度大。特別是，在決定采用分表之前，應(yīng)慎重考慮歸檔是不是一個更合理的選擇。

當(dāng)年做手游，發(fā)現(xiàn)游戲在4k屏的手機(jī)上運(yùn)行極慢，手機(jī)的GPU根本帶不動，嘗試了各種優(yōu)化手段都不好使。誰曾想，最終解決問題的，竟然是降低游戲的輸出分辨率。

算法上縮，物理上減，現(xiàn)在連國家不開始提倡65歲退休了，我們的老系統(tǒng)也一定能才堅持幾年。

五、『并』字訣

終于到了并發(fā)，一個大部分人都覺得應(yīng)該有用，同時大部分人覺得用起來發(fā)怵的優(yōu)化手段。

如果說前面的『池』、『序』、『分』、『減』這幾條頂多算工程技巧，憑著我們聰明的大腦&反復(fù)思考就有可能搞清楚的話，『并發(fā)』這一條就是一個學(xué)術(shù)問題。換句話說，即使經(jīng)過幾年的系統(tǒng)學(xué)習(xí)，也很少有人敢拍胸脯說自己的并發(fā)代碼無 bug。

并發(fā)真有這么難么？從編程語言的角度看，并發(fā)不就是多線程和死鎖么？賢者大神們的文章已經(jīng)解釋得很清楚了，像《不環(huán)保的死鎖：破解死鎖，我們一般從下三路入手》、《線程安全，唯快不破》，只要規(guī)避掉死鎖的幾個必要條件，還不是怎么順手怎么寫？而且，運(yùn)氣好的話還可以無鎖解決并發(fā)問題，不但準(zhǔn)，而且快。

然而真相遠(yuǎn)不是這么簡單。我們知道DB是解決數(shù)據(jù)安全和數(shù)據(jù)一致性問題的集大成者，我們嘗試從DB的角度來觀察一下。DB事務(wù)有ACID四個屬性，其中I是指隔離性Isolation，而它的研究核心就是并發(fā)問題。

毛爺爺說事務(wù)物是運(yùn)動發(fā)展的，我覺得他說的是對的。兩年之前還沒有新冠肺炎呢，今天它已經(jīng)像吃飯喝水一樣融入到了我們每個人的生活當(dāng)中。在早期的ANSI SQL92標(biāo)準(zhǔn)中，涉及到的并發(fā)異象只有4種，然而發(fā)展到今天，常見的并發(fā)異象已經(jīng)有7種之多，它們分別是：臟讀、臟寫、讀傾斜（不可重復(fù)讀）、寫傾斜，不可重復(fù)讀、幻讀、更新丟失。每一種并發(fā)異象都有不同的原因，以及不同的解決方案，而這還不是全部。其實(shí)我很想稍微給大家科普一下這些異象相關(guān)的內(nèi)容，但是我發(fā)現(xiàn)細(xì)節(jié)實(shí)在太多了。我盲猜后端的知識體系中，可能有一半都跟并發(fā)有關(guān)。

沒人否定當(dāng)年敲定SQL92標(biāo)準(zhǔn)的應(yīng)該算DB專家吧？連當(dāng)前ANSI的專家都沒能完全搞清楚事情，誰敢告訴我他輕松就能搞定？

所謂單機(jī)并發(fā)榨硬件，多機(jī)并發(fā)擴(kuò)上限（scale out）。當(dāng)單線程服務(wù)遭遇性能瓶頸，同時相應(yīng)的機(jī)器硬件還有富余的時候，進(jìn)行多線程改造從而充分壓榨硬件性能可能會是一個比較好的選擇。相應(yīng)的，當(dāng)單機(jī)性能已經(jīng)無法滿足服務(wù)需要的時候，就需要進(jìn)行分布式改造，通過水平擴(kuò)容的方式提升整體服務(wù)能力。這兩種思路，對應(yīng)到『分』字訣中，恰好是分表與分庫的區(qū)別：如果只是數(shù)據(jù)量上去了，CPU和內(nèi)存壓力都不大，那就分表再壓榨一下；反之，如果流量大增，單機(jī)負(fù)載已經(jīng)抗不住了，就可以考慮選擇分庫。

『并』字訣好使，但并不好掌握。引入并發(fā)會極大增大代碼復(fù)雜度，提高維持?jǐn)?shù)據(jù)一致性的難度。就像分庫分表一樣，它的痛，只有用過的人才知道，因此，往往只會作為終極優(yōu)化手段。不用則已，用則需要有面對困難的勇氣和決心。

六、優(yōu)化即置換

作為一名程序員，你一定聽過這樣一句話：好的架構(gòu)不是設(shè)計出來的，而是演化出來的。想要獲得什么，就要付出代價，就像想要討老婆，就得努力掙錢一樣。優(yōu)化會使代碼邏輯變得復(fù)雜，流程變得混亂。因此簡單設(shè)計，先上線，用錢堆，這些看起來很土的選擇很多時候可能比盲目優(yōu)化更能使我們遠(yuǎn)離漩渦。

但無論如何，經(jīng)常的，持續(xù)的分煎餅是個好習(xí)慣。

特別是山東煎餅，山東泰安的。