背景

前段時間，寫了一篇《高性能開發(fā)十大技術(shù)》，有讀者給我私信交流，····

曾經(jīng)，我面試的時候有兩個最怕的。一怕問算法，二怕問高并發(fā)。

算法這個，自從關(guān)注了「小浩算法」，刷了不少LeetCode，發(fā)現(xiàn)還是有套路可循的，雖不敢說算法能力有多強(qiáng)，至少沒有以前那么怕了(才怪)。

而第二個，高性能高并發(fā)技術(shù)，感覺有好多技術(shù)要學(xué)，東學(xué)一點(diǎn)，西學(xué)一點(diǎn)，不成體系。直到有一次面試，遇到了一個大牛，問到了這方面，結(jié)果被虐的體無完膚。幸運(yùn)的是，這位大牛不但技術(shù)一流，還認(rèn)真跟我交流了學(xué)習(xí)心得，怎么樣去有體系的系統(tǒng)去梳理這方面的技術(shù)知識，而不是瞎學(xué)。

CPU

不管什么樣到編程語言，什么樣到代碼框架，最終都是由CPU去執(zhí)行完成的(當(dāng)然這么說不太準(zhǔn)確，也有GPU、TPU、協(xié)處理器等其他情況，當(dāng)然這不是本文探討的重點(diǎn))。

所以要想提高性能，提高并發(fā)量，首要問題就是如何讓CPU跑的更快?

這個問題，也是一直以來CPU廠商一直在努力追求的方向。

如何讓CPU更快?CPU廠商做了兩個方面的努力：

• 加快指令執(zhí)行的速度
• 加快CPU讀取數(shù)據(jù)的速度

對于第一個方向，CPU執(zhí)行指令的快慢，是跟CPU的主頻緊密相關(guān)的，如何更快的取指令、指令譯碼、執(zhí)行，縮短CPU的指令周期，提升主頻在相當(dāng)長一段時間里都是非常有效的辦法。

從幾百M(fèi)Hz，到如今到幾GHz，CPU主頻有了長足的進(jìn)步，相同時間里能夠執(zhí)行的指令數(shù)變的更多了。

對于第二個方向，如何提升CPU讀取數(shù)據(jù)的速度，答案就是加緩存，利用局部性原理將內(nèi)存中經(jīng)常會訪問的數(shù)據(jù)搬運(yùn)到CPU中，這樣大大提升了存取速度。

從一級緩存，到二級緩存，乃至三級緩存，CPU緩存的層級和容量也在不斷提升，讀寫數(shù)據(jù)到時間省了不少。

但隨著時間到推移，尤其進(jìn)入21世紀(jì)之后，處理器廠商發(fā)現(xiàn)，進(jìn)一步提升主頻變得越來越困難了，CPU的緩存也很難進(jìn)一步擴(kuò)容。

怎么辦呢?既然一個人干活到速度已經(jīng)很難再提升，那何不多找?guī)讉€人一起干?于是，多核技術(shù)來了，一個CPU里面有多個核心，眾人劃槳開大船，CPU到速度再一次騰飛～

甚至，讓一個核在“閑暇時間”，利用“閑置資源”去執(zhí)行另外的線程，誕生了讓一個核“同時”執(zhí)行兩個線程的超線程技術(shù)。

上面簡單交代了為了提升性能，CPU所做的努力。但是光是CPU快是沒用的，還需要我們更好的去利用開發(fā)，否則就是對CPU算力的浪費(fèi)。

上面提到了線程，是的，如何提高性能，提高并發(fā)量?使用多線程技術(shù)當(dāng)然是一個非常好的思路。

但多線程的引入，就不得不提到兩個跟線程有關(guān)到話題：

• 線程同步
• 線程阻塞

多個線程協(xié)同工作，必然會引入同步的問題，常規(guī)解決方案是加鎖，加鎖的線程一般會進(jìn)入阻塞。

線程遇到阻塞了，就需要切換，而切換是有一定的成本開銷的，不僅是系統(tǒng)調(diào)度的時間開銷，還可能有CPU緩存失效的損失。

如果線程頻頻加鎖，頻頻阻塞，那這個損失就相當(dāng)可觀了。為了提升性能，無鎖編程技術(shù)就出現(xiàn)了，利用CPU提供的機(jī)制，提供更輕量的加鎖方案。

同時，為了讓切換后的線程仍然能夠在之前的CPU核心上運(yùn)行，降低緩存損失，線程的CPU親和性綁定技術(shù)也出現(xiàn)了。

現(xiàn)代操作系統(tǒng)都是以時間片的形式來調(diào)度分配給多個線程使用。如果時間片還沒用完就因?yàn)檫@樣或那樣的原因?qū)?zhí)行機(jī)會拱手相讓，那線程也太虧了。

于是，有人提出要充分利用CPU，別讓線程阻塞，交出執(zhí)行權(quán)，自己在應(yīng)用層實(shí)現(xiàn)多個執(zhí)行流的調(diào)度，這里阻塞了，就去執(zhí)行那里，總之要把時間片充分用完，這就誕生了協(xié)程技術(shù)，阻塞了不要緊，我還能干別的，不要輕易發(fā)生線程切換。

內(nèi)存

與CPU工作相關(guān)的第一親密伙伴就是內(nèi)存了，二者協(xié)作才能唱好一出戲。

提升內(nèi)存訪問的速度，同樣是高性能開發(fā)話題重要組成部分!

那如何提升呢?硬件層面程序員是很難改變到，咱們只好從軟件層面下功夫。

內(nèi)存的管理經(jīng)歷了從實(shí)地址模式到分頁式內(nèi)存管理，如今的計(jì)算機(jī)中，CPU拿到的地址都是虛擬地址，這中間就會涉及到地址到轉(zhuǎn)換，在這里就有文章可做，有兩個方向可以努力：

• 減少缺頁異常
• 使用大頁技術(shù)

現(xiàn)代操作系統(tǒng)，基本上都會使用一個叫換頁/交換文件的技術(shù)：內(nèi)存空間有限，但進(jìn)程越來越多，對內(nèi)存空間的需求越來越大，用完了怎么辦?于是在硬盤上劃分一塊區(qū)域出來，把內(nèi)存中很久不用的數(shù)據(jù)轉(zhuǎn)移到這塊區(qū)域上來，等程序用到的時候，觸發(fā)訪問異常，再在異常處理函數(shù)中將其從硬盤讀取進(jìn)來。

可以想象，如果程序訪問的內(nèi)存老是不在內(nèi)存中，而是被交換到了硬盤上，就會頻繁觸發(fā)缺頁異常，那程序的性能肯定大打折扣，所以減少缺頁異常也是提升性能的好辦法。

從虛擬地址尋址真實(shí)的物理內(nèi)存，這個過程是CPU完成的，具體來說，就是通過查表，從頁表->一級頁目錄->二級頁目錄->物理內(nèi)存。

頁目錄和頁表是存在內(nèi)存中的，毫無疑問，內(nèi)存尋址是一個非常非常高頻的事情，時時刻刻都在發(fā)生，而多次查表勢必是很慢的，有鑒于此，CPU引入了一個叫TLB(Translation Look- aside buffer)的東西，使用緩存頁表項(xiàng)的方式來減少內(nèi)存查表的操作，加快尋址速度。

默認(rèn)情況下，操作系統(tǒng)是以4KB為單位管理內(nèi)存頁的，對于一些需要大量內(nèi)存的服務(wù)器程序(Redis、JVM、ElascticSearch等等)，動輒就是幾十個G，按照4KB的單位劃分，那得產(chǎn)生多少的頁表項(xiàng)啊!

而CPU中的TLB的大小是有限的，內(nèi)存越多，頁表項(xiàng)也就越多，TLB緩存失效的概率也就越大。所以，大頁內(nèi)存技術(shù)就出現(xiàn)了，4KB太小，就弄大點(diǎn)。大頁內(nèi)存技術(shù)的出現(xiàn)，減少了缺頁異常的出現(xiàn)次數(shù)，也提高了TLB命中的概率，對于提升性能有很大的幫助。

在一些高配置的服務(wù)器上，內(nèi)存數(shù)量龐大，而CPU多個核都要通過內(nèi)存總線訪問內(nèi)存，可想而知，CPU核數(shù)上去以后，內(nèi)存總線的競爭勢必也會加劇。于是NUMA架構(gòu)出現(xiàn)了，把CPU核心劃分不同的分組，各自使用自己的內(nèi)存訪問總線，提高內(nèi)存的訪問速度。

I/O

CPU和內(nèi)存都夠快了，但這還是不夠。我們的程序日常工作中，除了一些CPU密集型的程序(執(zhí)行數(shù)學(xué)運(yùn)算，加密解密，機(jī)器學(xué)習(xí)等等)以外，相當(dāng)一部分時間都是在執(zhí)行I/O，如讀寫硬盤文件、收發(fā)網(wǎng)絡(luò)數(shù)據(jù)包等等。

所以，如何提升I/O的速度，是高性能開發(fā)技術(shù)領(lǐng)域一個重要的話題。

因?yàn)镮/O會涉及到與外設(shè)(硬盤、網(wǎng)卡等)的交互，而這些外設(shè)又通常是非常慢(相對CPU執(zhí)行速度)的，所以正常情況下，線程執(zhí)行到I/O操作時難免會阻塞，這也是前面在CPU部分提到過的。

阻塞以后那就沒辦法干活了，為了能干活，那就開多個線程。但線程資源是很昂貴的，沒辦法大量使用，況且線程多了，多個線程切換調(diào)度同樣是很花時間的。

那可不可以讓線程執(zhí)行I/O時不阻塞呢?于是，新的技術(shù)又出現(xiàn)了：

• 非阻塞I/O
• I/O多路復(fù)用
• 異步I/O

原來的阻塞I/O是一直等，等到I/O的完成，非阻塞I/O一般是輪詢，可以去干別的事，過一會兒就來問一下：好了沒有?

但每個線程都去輪詢也不是個事兒啊，干脆交給一個線程去專門負(fù)責(zé)吧，這就是I/O多路復(fù)用，通過select/poll的方式只用一個線程就可以處理多個I/O目標(biāo)。再然后，再改進(jìn)一下，用epoll，連輪詢也不用了，改用內(nèi)核喚醒通知的機(jī)制，同時處理的I/O目標(biāo)還更多了。

異步I/O就更爽了，設(shè)置一個回調(diào)函數(shù)，自己干別的事去了，回頭操作系統(tǒng)叫你來收數(shù)據(jù)就好了。

再說回到I/O本身，會將數(shù)據(jù)在內(nèi)存和外設(shè)之間傳輸，如果數(shù)據(jù)量很大，讓CPU去搬運(yùn)數(shù)據(jù)的話，既耗時又沒有技術(shù)含量，這是對CPU算力的很大浪費(fèi)。

所以，為了將CPU從中解放出來，又誕生了一門技術(shù)：直接內(nèi)存訪問DMA，把數(shù)據(jù)的傳輸工作外包出去，交由DMA控制器來完成，CPU只在背后發(fā)號施令即可。

有了DMA，再也不用麻煩CPU去執(zhí)行數(shù)據(jù)的搬運(yùn)工作。但對于應(yīng)用程序而言，想要把文件通過網(wǎng)絡(luò)發(fā)送出去，還是要把數(shù)據(jù)在內(nèi)核態(tài)空間和用戶態(tài)空間來回折騰兩次，這兩步還得CPU出馬去復(fù)制拷貝，屬于一種浪費(fèi)，為了解決這個問題，提升性能，又進(jìn)一步產(chǎn)生了零拷貝技術(shù)，徹底為CPU減負(fù)。

算法架構(gòu)

CPU、內(nèi)存、I/O都夠快了，單臺計(jì)算機(jī)的性能已經(jīng)很難提升了。不過，現(xiàn)在的服務(wù)器很少是單打獨(dú)斗了，接下來就要把目光轉(zhuǎn)移到算法、架構(gòu)上來了。

一臺服務(wù)器搞不定，那就用硬件堆出性能來，分布式集群技術(shù)和負(fù)載均衡技術(shù)就派上用場了。

這年頭，哪個后端服務(wù)沒有數(shù)據(jù)庫?如何讓數(shù)據(jù)庫更快?該輪到索引技術(shù)上了，通過給數(shù)據(jù)庫建立索引，提升檢索速度。

但數(shù)據(jù)庫這家伙的數(shù)據(jù)畢竟是存在硬盤上的，讀取的時候勢必會慢，要是大量的數(shù)據(jù)請求都懟上來，這誰頂?shù)米?于是基于內(nèi)存的數(shù)據(jù)庫緩存Redis、Memcached應(yīng)運(yùn)而生，畢竟，訪問內(nèi)存比從數(shù)據(jù)庫查詢快得多。

算法架構(gòu)這一塊的技術(shù)實(shí)在太多了，也是從一個普通碼農(nóng)通往架構(gòu)師的必經(jīng)之路，咱們下回再聊。

總結(jié)

高性能、高并發(fā)是后端開發(fā)永恒追求的話題。

每一項(xiàng)技術(shù)都不是憑空出現(xiàn)的，一定是為了解決某個問題而提出。我們在學(xué)這些技術(shù)的時候，掌握它出現(xiàn)的原因，和其他技術(shù)之間的關(guān)聯(lián)，在自己的大腦中建立一座技術(shù)知識層級圖，一定能事半功倍。

這幅圖中的絕大多數(shù)技術(shù)，我之前都有對應(yīng)的趣味故事文章進(jìn)行闡述，歡迎大家去翻一番～

本文轉(zhuǎn)載自微信公眾號「編程技術(shù)宇宙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系編程技術(shù)宇宙公眾號。