文章出自：阿里巴巴十億級并發系統設計（2021版）

鏈接：https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA?提取碼：8888?

我們知道，高并發代表著大流量，高并發系統設計的魅力就在于我們能夠憑借自己的聰明才智設計巧妙的方案，從而抵抗巨大流量的沖擊，帶給用戶更好的使用體驗。這些方案好似能操縱流量，讓流量更加平穩得被系統中的服務和組件處理。來做個簡單的比喻吧。從古至今，長江和黃河流域水患不斷，遠古時期，大禹曾拓寬河道，清除淤沙讓流水更加順暢；都江堰作為史上最成功的的治水案例之一，用引流將岷江之水分流到多個支流中，以分擔水流壓力;三門峽和葛洲壩通過建造水庫將水引入水庫先存儲起來，然后再想辦法把水庫中的水緩緩地排出去，以此提高下游的抗洪能力。而我們在應對高并發大流量時也會采用類似“抵御洪水”的方案，歸納起來共有三種方法：

Scale-out(橫向擴展)：分而治之是一種常見的高并發系統設計方法，采用分布式部署 的方式把流量分流開，讓每個服務器都承擔一部分并發和流量。

緩存：使用緩存來提高系統的性能，就好比用“拓寬河道”的方式抵抗高并發大流量的沖擊。

異步：在某些場景下，未處理完成之前，我們可以讓請求先返回，在數據準備好之后再通知請求方，這樣可以在單位時間內處理更多的請求。

簡單介紹了這三種方法之后，我再詳細地帶你了解一下，這樣當你在設計高并發系統時就可以有考慮的方向了。當然了，這三種方法會細化出更多的內容，我會在后面的課程中深講解。

首先，我們先來了解第一種方法:Scale-out。?Scale-up vs Scale-out

著名的“摩爾定律”是由 Intel 的創始人之一戈登·摩爾于 1965 年提出的。這個定律提到， 集成電路上可容納的晶體管的數量約每隔兩年會增加一倍。后來，Intel 首席執行官大衛·豪斯提出“18 個月”的說法，即預計 18 個月會將芯片的性能 提升一倍，這個說法廣為流傳。摩爾定律雖然描述的是芯片的發展速度，但我們可以延伸為整體的硬件性能，從 20 世紀后 半葉開始，計算機硬件的性能是指數級演進的。直到現在，摩爾定律依然生效，在半個世紀以來的 CPU 發展過程中，芯片廠商靠著在有限 面積上做更小的晶體管的黑科技，大幅度地提升著芯片的性能。從第一代集成電路上只有十 幾個晶體管，到現在一個芯片上動輒幾十億晶體管的數量，摩爾定律指引著芯片廠商完成了 技術上的飛躍。但是有專家預測，摩爾定律可能在未來幾年之內不再生效，原因是目前的芯片技術已經做到 了 10nm 級別，在工藝上已經接近極限，再往上做，即使有新的技術突破，在成本上也難 以被市場接受。后來，雙核和多核技術的產生拯救了摩爾定律，這些技術的思路是將多個 CPU 核心壓在一個芯片上，從而大大提升 CPU 的并行處理能力。

我們在高并發系統設計上也沿用了同樣的思路，將類似追逐摩爾定律不斷提升 CPU 性能的 方案叫做 Scale-up(縱向擴展)，把類似 CPU 多核心的方案叫做 Scale-out，這兩種思路 在實現方式上是完全不同的。Scale-up，通過購買性能更好的硬件來提升系統的并發處理能力，比方說目前系統 4 核 4G 每秒可以處理 200 次請求，那么如果要處理 400 次請求呢?很簡單，我們把機器的 硬件提升到 8 核 8G(硬件資源的提升可能不是線性的，這里僅為參考)。Scale-out，則是另外一個思路，它通過將多個低性能的機器組成一個分布式集群來共同抵御高并發流量的沖擊。沿用剛剛的例子，我們可以使用兩臺 4 核 4G 的機器來處理那 400 次請求。

那么什么時候選擇 Scale-up，什么時候選擇 Scale-out 呢?一般來講，在我們系統設計初 期會考慮使用 Scale-up 的方式，因為這種方案足夠簡單，所謂能用堆砌硬件解決的問題就 用硬件來解決，但是當系統并發超過了單機的極限時，我們就要使用 Scale-out 的方式。Scale-out 雖然能夠突破單機的限制，但也會引入一些復雜問題。比如，如果某個節點出現 故障如何保證整體可用性?當多個節點有狀態需要同步時，如何保證狀態信息在不同節點的 一致性?如何做到使用方無感知的增加和刪除節點?等等。其中每一個問題都涉及很多的知 識點，我會在后面的課程中深入地講解，這里暫時不展開了。

說完了 Scale-out，我們再來看看高并發系統設計的另一種方法:緩存。?使用緩存提升性能

Web 2.0 是緩存的時代，這一點毋庸置疑。緩存遍布在系統設計的每個角落，從操作系統 到瀏覽器，從數據庫到消息隊列，任何略微復雜的服務和組件中，你都可以看到緩存的影 子。我們使用緩存的主要作用是提升系統的訪問性能，那么在高并發的場景下，就可以支撐 更多用戶的同時訪問。那么為什么緩存可以大幅度提升系統的性能呢?我們知道數據是放在持久化存儲中的，一般的持久化存儲都是使用磁盤作為存儲介質的，而普通磁盤數據由機械手臂、磁頭、轉軸、盤片組成，盤片又分為磁道、柱面和扇區，盤片構造圖我放在下面了。盤片是存儲介質，每個盤片被劃分為多個同心圓，信息都被存儲在同心圓之中，這些同心圓就是磁道。在磁盤工作時盤片是在高速旋轉的，機械手臂驅動磁頭沿著徑向移動，在磁道上讀取所需要的數據。我們把磁頭尋找信息花費的時間叫做尋道時間。

普通磁盤的尋道時間是 10ms 左右，而相比于磁盤尋道花費的時間，CPU 執行指令和內存 尋址的時間都在是 ns(納秒)級別，從千兆網卡上讀取數據的時間是在μs(微秒)級別。 所以在整個計算機體系中，磁盤是最慢的一環，甚至比其它的組件要慢幾個數量級。因此， 我們通常使用以內存作為存儲介質的緩存，以此提升性能。當然，緩存的語義已經豐富了很多，我們可以將任何降低響應時間的中間存儲都稱為緩存。 緩存的思想遍布很多設計領域，比如在操作系統中 CPU 有多級緩存，文件有 Page Cache 緩存，你應該有所了解。

異步處理

異步也是一種常見的高并發設計方法，我們在很多文章和演講中都能聽到這個名詞，與之共 同出現的還有它的反義詞:同步。比如，分布式服務框架 Dubbo 中有同步方法調用和異步 方法調用，IO 模型中有同步 IO 和異步 IO。那么什么是同步，什么是異步呢?以方法調用為例，同步調用代表調用方要阻塞等待被調用 方法中的邏輯執行完成。這種方式下，當被調用方法響應時間較長時，會造成調用方長久的阻塞，在高并發下會造成整體系統性能下降甚至發生雪崩。

異步調用恰恰相反，調用方不需要等待方法邏輯執行完成就可以返回執行其他的邏輯，在被調用方法執行完畢后再通過回調、事件通知等方式將結果反饋給調用方。異步調用在大規模高并發系統中被大量使用，比如我們熟知的 12306 網站。當我們訂票 時，頁面會顯示系統正在排隊，這個提示就代表著系統在異步處理我們的訂票請求。在 12306 系統中查詢余票、下單和更改余票狀態都是比較耗時的操作，可能涉及多個內部系 統的互相調用，如果是同步調用就會像 12306 剛剛上線時那樣，高峰期永遠不可能下單成功。而采用異步的方式，后端處理時會把請求丟到消息隊列中，同時快速響應用戶，告訴用戶我們正在排隊處理，然后釋放出資源來處理更多的請求。訂票請求處理完之后，再通知用戶訂票成功或者失敗。處理邏輯后移到異步處理程序中，Web 服務的壓力小了，資源占用的少了，自然就能接收更多的用戶訂票請求，系統承受高并發的能力也就提升了。

既然我們了解了這三種方法，那么是不是意味著在高并發系統設計中，開發一個系統時要把這些方法都用上呢?當然不是，系統的設計是不斷演進的。羅馬不是一天建成的，系統的設計也是如此。不同量級的系統有不同的痛點，也就有不同的 架構設計的側重點。如果都按照百萬、千萬并發來設計系統，電商一律向淘寶看齊，IM 全 都學習微信和 QQ，那么這些系統的命運一定是滅亡。

因為淘寶、微信的系統雖然能夠解決同時百萬、千萬人同時在線的需求，但其內部的復雜程度也遠非我們能夠想象的。盲目地追從只能讓我們的架構復雜不堪，最終難以維護。就拿從單體架構往服務化演進來說，淘寶也是在經歷了多年的發展后，發現系統整體的擴展能力出現問題時，開始啟動服務化改造項目的。我之前也踩過一些坑，參與的一個創業項目在初始階段就采用了服務化的架構，但由于當時 人力有限，團隊技術積累不足，因此在實際項目開發過程中，發現無法駕馭如此復雜的架 構，也出現了問題難以定位、系統整體性能下降等多方面的問題，甚至連系統宕機了都很難 追查到根本原因，最后不得不把服務做整合，回歸到簡單的單體架構中。所以我建議一般系統的演進過程應該遵循下面的思路:

• 最簡單的系統設計滿足業務需求和流量現狀，選擇最熟悉的技術體系。
• 隨著流量的增加和業務的變化，修正架構中存在問題的點，如單點問題，橫向擴展問題，性能無法滿足需求的組件。在這個過程中，選擇社區成熟的、團隊熟悉的組件幫助我們解決問題，在社區沒有合適解決方案的前提下才會自己造輪子。
• 當對架構的小修小補無法滿足需求時，考慮重構、重寫等大的調整方式以解決現有的問題。

以淘寶為例，當時在業務從 0 到 1 的階段是通過購買的方式快速搭建了系統。而后，隨著流量的增長，淘寶做了一系列的技術改造來提升高并發處理能力，比如數據庫存儲引擎從 MyISAM 遷移到 InnoDB，數據庫做分庫分表，增加緩存，啟動中間件研發等。當這些都無法滿足時就考慮對整體架構做大規模重構，比如說著名的“五彩石”項目讓淘寶的架構從單體演進為服務化架構。正是通過逐步的技術演進，淘寶才進化出如今承擔過億 QPS 的技術架構。歸根結底一句話:高并發系統的演進應該是循序漸進，以解決系統中存在的問題為目的和驅動力的。

課程小結

在今天的課程中，我帶著你了解了高并發系統設計的三種通用方法:Scale-out、緩存和異 步。這三種方法可以在做方案設計時靈活地運用，但它不是具體實施的方案，而是三種思 想，在實際運用中會千變萬化。就拿 Scale-out 來說，數據庫一主多從、分庫分表、存儲分片都是它的實際應用方案。而我們需要注意的是，在應對高并發大流量的時候，系統是可以通過增加機器來承擔流量沖擊的，至于要采用什么樣的方案還是要具體問題具體分析。

總結

以上是生活随笔為你收集整理的高并发系统—通用设计方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。