高并发系统—高性能
文章出自：阿里巴巴十億級并發(fā)系統(tǒng)設計（2021版）
鏈接：https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA?提取碼：8888?
目錄
高并發(fā)系統(tǒng)設計的三大目標：高性能、高可用、可擴展
性能優(yōu)化原則
性能的度量指標
高并發(fā)下的性能優(yōu)化
課程小結(jié)
提到互聯(lián)網(wǎng)系統(tǒng)設計，你可能聽到最多的詞兒就是“三高”，也就是“高并發(fā)”、“高性能”、“高可用”，它們是互聯(lián)網(wǎng)系統(tǒng)架構(gòu)設計永恒的主題。在前兩節(jié)課中，我?guī)懔私饬烁卟l(fā)系統(tǒng)設計的含義、意義以及分層設計原則，接下來，我想帶你整體了解一下高并發(fā)系統(tǒng)設計的目標，然后在此基礎上，進入我們今天的話題:如何提升系統(tǒng)的性能?
高并發(fā)系統(tǒng)設計的三大目標：高性能、高可用、可擴展
高并發(fā)，是指運用設計手段讓系統(tǒng)能夠處理更多的用戶并發(fā)請求，也就是承擔更大的流量。 它是一切架構(gòu)設計的背景和前提，脫離了它去談性能和可用性是沒有意義的。很顯然嘛，你 在每秒一次請求和每秒一萬次請求，兩種不同的場景下，分別做到毫秒級響應時間和五個九 (99.999%)的可用性，無論是設計難度還是方案的復雜度，都不是一個級別的。
而性能和可用性，是我們實現(xiàn)高并發(fā)系統(tǒng)設計必須考慮的因素。 性能反應了系統(tǒng)的使用體驗，想象一下，同樣承擔每秒一萬次請求的兩個系統(tǒng)，一個響應時間是毫秒級，一個響應時間在秒級別，它們帶給用戶的體驗肯定是不同的。
可用性則表示系統(tǒng)可以正常服務用戶的時間。我們再類比一下，還是兩個承擔每秒一萬次的 系統(tǒng)，一個可以做到全年不停機、無故障，一個隔三差五宕機維護，如果你是用戶，你會選 擇使用哪一個系統(tǒng)呢?答案不言而喻。
另一個耳熟能詳?shù)拿~叫“可擴展性”，它同樣是高并發(fā)系統(tǒng)設計需要考慮的因素。為什么 呢?我來舉一個具體的例子。流量分為平時流量和峰值流量兩種，峰值流量可能會是平時流量的幾倍甚至幾十倍，在應對峰值流量的時候，我們通常需要在架構(gòu)和方案上做更多的準備。這就是淘寶會花費大半年的時間準備雙十一，也是在面對“明星離婚”等熱點事件時，看起來無懈可擊的微博系統(tǒng)還是會出現(xiàn)服務不可用的原因。而易于擴展的系統(tǒng)能在短時間內(nèi)迅速完成擴容，更加平穩(wěn)地承擔峰值流量。
高性能、高可用和可擴展，是我們在做高并發(fā)系統(tǒng)設計時追求的三個目標，我會用三節(jié)課的 時間，帶你了解在高并發(fā)大流量下如何設計高性能、高可用和易于擴展的系統(tǒng)。
了解完這些內(nèi)容之后，我們正式進入今天的話題:如何提升系統(tǒng)的性能?
性能優(yōu)化原則
“天下武功，唯快不破”。性能是系統(tǒng)設計成功與否的關鍵，實現(xiàn)高性能也是對程序員個人能力的挑戰(zhàn)。不過在了解實現(xiàn)高性能的方法之前，我們先明確一下性能優(yōu)化的原則。
在以上四個原則的指引下，掌握常見性能問題的排查方式和優(yōu)化手段，就一定能讓你在設計高并發(fā)系統(tǒng)時更加游刃有余。
性能的度量指標
性能優(yōu)化的第三點原則中提到，對于性能我們需要有度量的標準，有了數(shù)據(jù)才能明確目前存在的性能問題，也能夠用數(shù)據(jù)來評估性能優(yōu)化的效果。所以明確性能的度量指標十分重要。一般來說，度量性能的指標是系統(tǒng)接口的響應時間，但是單次的響應時間是沒有意義的，你 需要知道一段時間的性能情況是什么樣的。所以，我們需要收集這段時間的響應時間數(shù)據(jù)， 然后依據(jù)一些統(tǒng)計方法計算出特征值，這些特征值就能夠代表這段時間的性能情況。我們常 見的特征值有以下幾類。
平均值
顧名思義，平均值是把這段時間所有請求的響應時間數(shù)據(jù)相加，再除以總請求數(shù)。平均值可以在一定程度上反應這段時間的性能，但它敏感度比較差，如果這段時間有少量慢請求時， 在平均值上并不能如實的反應。
舉個例子，假設我們在 30s 內(nèi)有 10000 次請求，每次請求的響應時間都是 1ms，那么這段時間響應時間平均值也是 1ms。這時，當其中 100 次請求的響應時間變成了 100ms， 那么整體的響應時間是 (100 * 100 + 9900 * 1) / 10000 = 1.99ms。你看，雖然從平均值上來看僅僅增加了不到 1ms，但是實際情況是有 1% 的請求(100/10000)的響應時間已經(jīng)增加了 100 倍。所以，平均值對于度量性能來說只能作為一個參考。
最大值
這個更好理解，就是這段時間內(nèi)所有請求響應時間最長的值，但它的問題又在于過于敏感 了。 還拿上面的例子來說，如果 10000 次請求中只有一次請求的響應時間達到 100ms，那么這段時間請求的響應耗時的最大值就是 100ms，性能損耗為原先的百分之一，這種說法明顯是不準確的。
分位值
分位值有很多種，比如 90 分位、95 分位、75 分位。以 90 分位為例，我們把這段時間請求的響應時間從小到大排序，假如一共有 100 個請求，那么排在第 90 位的響應時間就是 90 分位值。分位值排除了偶發(fā)極慢請求對于數(shù)據(jù)的影響，能夠很好地反應這段時間的性能情況，分位值越大，對于慢請求的影響就越敏感。
在我來看，分位值是最適合作為時間段內(nèi)，響應時間統(tǒng)計值來使用的，在實際工作中也應用最多。除此之外，平均值也可以作為一個參考值來使用。
我在上面提到，脫離了并發(fā)來談性能是沒有意義的，我們通常使用吞吐量或者同時在線用戶數(shù)來度量并發(fā)和流量，使用吞吐量的情況會更多一些。但是你要知道，這兩個指標是呈倒數(shù)關系的。這很好理解，響應時間 1s 時，吞吐量是每秒 1 次，響應時間縮短到 10ms，那么吞吐量就 上升到每秒 100 次。所以，一般我們度量性能時都會同時兼顧吞吐量和響應時間，比如我們設立性能優(yōu)化的目標時通常會這樣表述:在每秒 1 萬次的請求量下，響應時間 99 分位值 在 10ms 以下。
那么，響應時間究竟控制在多長時間比較合適呢?這個不能一概而論。
從用戶使用體驗的角度來看，200ms 是第一個分界點:接口的響應時間在 200ms 之內(nèi)， 用戶是感覺不到延遲的，就像是瞬時發(fā)生的一樣。而 1s 是另外一個分界點:接口的響應時 間在 1s 之內(nèi)時，雖然用戶可以感受到一些延遲，但卻是可以接受的，超過 1s 之后用戶就會有明顯等待的感覺，等待時間越長，用戶的使用體驗就越差。所以，健康系統(tǒng)的 99 分位值的響應時間通常需要控制在 200ms 之內(nèi)，而不超過 1s 的請求占比要在 99.99% 以上。現(xiàn)在你了解了性能的度量指標，那我們再來看一看，隨著并發(fā)的增長我們實現(xiàn)高性能的思路 是怎樣的。
高并發(fā)下的性能優(yōu)化
假如說，你現(xiàn)在有一個系統(tǒng)，這個系統(tǒng)中處理核心只有一個，執(zhí)行的任務的響應時間都在 10ms，它的吞吐量是在每秒 100 次。那么我們?nèi)绾蝸韮?yōu)化性能從而提高系統(tǒng)的并發(fā)能力 呢?主要有兩種思路：一種是提高系統(tǒng)的處理核心數(shù)，另一種是減少單次任務的響應時間。
1. 提高系統(tǒng)的處理核心數(shù)
提高系統(tǒng)的處理核心數(shù)就是增加系統(tǒng)的并行處理能力，這個思路是優(yōu)化性能最簡單的途徑。 拿上一個例子來說，你可以把系統(tǒng)的處理核心數(shù)增加為兩個，并且增加一個進程，讓這兩個進程跑在不同的核心上。這樣從理論上，你系統(tǒng)的吞吐量可以增加一倍。當然了，在這種情 況下，吞吐量和響應時間就不是倒數(shù)關系了，而是:吞吐量 = 并發(fā)進程數(shù) / 響應時間。計算機領域的阿姆達爾定律(Amdahl’s law)是吉恩·阿姆達爾在 1967 年提出的。它描 述了并發(fā)進程數(shù)與響應時間之間的關系，含義是在固定負載下，并行計算的加速比，也就是 并行化之后效率提升情況，可以用下面公式來表示：(Ws + Wp) / (Ws + Wp/s)，其中，Ws 表示任務中的串行計算量，Wp 表示任務中的并行計算量，s 表示并行進程數(shù)。
從這個公式我們可以推導出另外一個公式：1/(1-p+p/s)其中，s 還是表示并行進程數(shù)，p 表示任務中并行部分的占比。當 p 為 1 時，也就是完全 并行時，加速比與并行進程數(shù)相等;當 p 為 0 時，即完全串行時，加速比為 1，也就是說完全無加速;當 s 趨近于無窮大的時候，加速比就等于 1/(1-p)，你可以看到它完全和 p 成 正比。特別是，當 p 為 1 時，加速比趨近于無窮大。
以上公式的推導過程有些復雜，你只需要記住結(jié)論就好了。
我們似乎找到了解決問題的銀彈，是不是無限制地增加處理核心數(shù)就能無限制地提升性能， 從而提升系統(tǒng)處理高并發(fā)的能力呢?很遺憾，隨著并發(fā)進程數(shù)的增加，并行的任務對于系統(tǒng)資源的爭搶也會愈發(fā)嚴重。在某一個臨界點上繼續(xù)增加并發(fā)進程數(shù)，反而會造成系統(tǒng)性能的下降，這就是性能測試中的拐點模型。
從圖中你可以發(fā)現(xiàn)，并發(fā)用戶數(shù)處于輕壓力區(qū)時，響應時間平穩(wěn)，吞吐量和并發(fā)用戶數(shù)線性 相關。而當并發(fā)用戶數(shù)處于重壓力區(qū)時，系統(tǒng)資源利用率到達極限，吞吐量開始有下降的趨 勢，響應時間也會略有上升。這個時候，再對系統(tǒng)增加壓力，系統(tǒng)就進入拐點區(qū)，處于超負荷狀態(tài)，吞吐量下降，響應時間大幅度上升。 所以我們在評估系統(tǒng)性能時通常需要做壓力測試，目的就是找到系統(tǒng)的“拐點”，從而知道系統(tǒng)的承載能力，也便于找到系統(tǒng)的瓶頸，持續(xù)優(yōu)化系統(tǒng)性能。
說完了提升并行能力，我們再看看優(yōu)化性能的另一種方式:減少單次任務響應時間。
2. 減少單次任務響應時間
想要減少任務的響應時間，首先要看你的系統(tǒng)是 CPU 密集型還是 IO 密集型的，因為不同 類型的系統(tǒng)性能優(yōu)化方式不盡相同。
CPU 密集型系統(tǒng)中，需要處理大量的 CPU 運算，那么選用更高效的算法或者減少運算次數(shù) 就是這類系統(tǒng)重要的優(yōu)化手段。比方說，如果系統(tǒng)的主要任務是計算 Hash 值，那么這時選用更高性能的 Hash 算法就可以大大提升系統(tǒng)的性能。發(fā)現(xiàn)這類問題的主要方式，是通過一些 Profile 工具來找到消耗 CPU 時間最多的方法或者模塊，比如 Linux 的 perf、eBPF 等。
IO 密集型系統(tǒng)指的是系統(tǒng)的大部分操作是在等待 IO 完成，這里 IO 指的是磁盤 IO 和網(wǎng)絡 IO。我們熟知的系統(tǒng)大部分都屬于 IO 密集型，比如數(shù)據(jù)庫系統(tǒng)、緩存系統(tǒng)、Web 系統(tǒng)。 這類系統(tǒng)的性能瓶頸可能出在系統(tǒng)內(nèi)部，也可能是依賴的其他系統(tǒng)，而發(fā)現(xiàn)這類性能瓶頸的手段主要有兩類。
第一類是采用工具，Linux 的工具集很豐富，完全可以滿足你的優(yōu)化需要，比如網(wǎng)絡協(xié)議 棧、網(wǎng)卡、磁盤、文件系統(tǒng)、內(nèi)存，等等。這些工具的用法很多，你可以在排查問題的過程中逐漸積累。除此之外呢，一些開發(fā)語言還有針對語言特性的分析工具，比如說 Java 語言 就有其專屬的內(nèi)存分析工具。
另外一類手段就是可以通過監(jiān)控來發(fā)現(xiàn)性能問題。在監(jiān)控中我們可以對任務的每一個步驟做分時的統(tǒng)計，從而找到任務的哪一步消耗了更多的時間。這一部分在演進篇中會有專門的介紹，這里就不再展開了。
那么找到了系統(tǒng)的瓶頸點，我們要如何優(yōu)化呢?優(yōu)化方案會隨著問題的不同而不同。比方說，如果是數(shù)據(jù)庫訪問慢，那么就要看是不是有鎖表的情況、是不是有全表掃描、索引加得是否合適、是否有 JOIN 操作、需不需要加緩存，等等;如果是網(wǎng)絡的問題，就要看網(wǎng)絡的參數(shù)是否有優(yōu)化的空間，抓包來看是否有大量的超時重傳，網(wǎng)卡是否有大量丟包等。
總而言之，“兵來將擋水來土掩”，我們需要制定不同的性能優(yōu)化方案來應對不同的性能問 題。
課程小結(jié)
今天，我?guī)懔私饬诵阅艿脑瓌t、度量指標，以及在高并發(fā)下優(yōu)化性能的基本思路。性能優(yōu)化是一個很大的話題，只用短短一講是完全不夠的，所以我會在后面的課程中詳細介紹其中的某些方面，比方說我們?nèi)绾斡镁彺鎯?yōu)化系統(tǒng)的讀取性能，如何使用消息隊列優(yōu)化系統(tǒng)的寫入性能等等。 有時候你在遇到性能問題的時候會束手無策，從今天的課程中你可以得到一些啟示，在這里 我給你總結(jié)出幾點:
總結(jié)
- 上一篇： 高并发系统—通用设计方法
- 下一篇： 高并发系统—高可用