高併發系統通用設計方法是什麼？
高併發代表着大流量，舉個例子，從古至今對黃河的治理，大禹治水是拓寬河道，清除淤泥，讓水流更通暢，流向大海。都江堰是通過引流的方式將岷江之水分流到多個支流，分擔水流壓力。三峽門和葛洲壩採用的是建造水庫的方式將水儲存起來然後把水庫中的水緩緩排出去，提高下游抗洪能力。
高併發系統的設計三種思路
上面的例子也提到了三個例子，其實代表了高併發系統設計的三種思路。
- Scale-out(橫向擴展)：分而治之的思想，在算法中也常見，這是一種常見的高併發系統設計思路，採用分佈式部署方案，將流量分開，讓每個服務器都承擔一定流量。
- 緩存：使用緩存來提高系統的性能，好比“拓寬河道”的方式抵抗高併發流量的衝擊。
- 異步：在某些場景下，未處理完成之前，我們可以讓請求先返回，在數據準備好之後再通知請求方，這樣可以在單位時間內處理更多的請求。
橫向擴展，縱向擴展 Scale-up vs Scale-out
Scale-up （縱向擴展） Scale-out(橫向擴展)。
舉個例子，摩爾定律，摩爾定律是指每18個月 CPU 的性能要翻一倍。這種不斷追逐摩爾定律，不斷提升 CPU 的方案，就叫做 Scale-up(縱向擴展)，把類似CPU 多核心的方案叫做 Scale-out（橫向擴展）。
- Scale-up: 通過構面更好的硬件來提升系統的併發處理能力，比如從硬件 4核 4G 每秒處理 200 次請求， 那麼如果要處理 400 次請求呢，例如可以把硬件升級到 8核 8G
- Scale-out ，則是另外一個思路，可以通過多個低性能的集羣組成一個分佈式集羣來共同抵禦高併發流量的衝擊。 比如可以使用兩臺 4 核 4G 的機器來處理每秒 400 次請求。
scale-up 與 sclae-out 如何選擇
系統設計最初的時候，會考慮使用 Scale-up 的方式，因爲此方法簡單，升級相關硬件就可以，但是當系統併發突破了單臺機器的基線時，這個時候，就需要考慮scale-out 的方式。
scale-out 雖然突破了單機的限制，但是會出現分佈式系統的問題，就是分佈式系統中的 CAP 理論，如何保證多個節點的數據一致性？如何保證系統的可用性？
如何無感知的增加或者刪除節點？
使用緩存提升性能
大禹治水的時候疏通淤泥，防止阻塞，提高性能。
緩存主要是在高併發系統情況下，能夠支撐多用戶同時訪問。主要是緩存的高性能，基於數據庫存儲，一般的持久化都是使用磁盤作爲存儲介質。通過機械，磁頭，轉軸等方式訪問磁道和扇區。這個速度肯定不會特別快。
一般來說磁盤尋磁道的時間大概是 10ms 左右。相對磁盤的花費時間，CPU 執行指令，和內存尋址的時間都是 ns級別。從千兆網卡是讀取的時間是 us 微秒級別。整個計算機體系中，磁盤是最慢的，這也是爲啥很多計算機升級成固態硬盤。我們常說的緩存，一般是以內存作爲存儲介質的。可以提升性能。
異步
異步也是高併發系統的一種設計思路，反義詞是同步。
-
同步，當進行同步操作時，需要進行等待調用返回，才繼續往下進行。
-
異步: 不需要等待當前調用返回，通常通過事件或者回調機制來實現任務建調用次序。
同步會阻塞等待被調用方的邏輯執行完成，纔會繼續往下執行，這樣存在個問題，當被調用方法響應時間長時，會造成調用方長久阻塞，在高併發的情況下會出現整個系統性能下降，甚至發生雪崩。
異步調用在高併發系統中經常被調用，大家熟悉的 12306 就是，訂票時，可以看到系統顯示在排隊，其實這個就表示在異步處理我們的訂票請求。 其次 12306 系統中的餘票查詢，下單，更改餘票狀態，這些操作都是耗時操作，一般是採用異步的方式，將請求丟到消息隊列中，同時快速響應用戶，告訴用戶正在排隊處理，然後釋放資源出來處理更多的請求，訂票請求完成後，再通知用戶是訂票成功還是失敗。
系統設計演進過程思路
羅馬不是一天建成的！高併發系統的演進應該是循序漸進，以解決系統中存在的問題爲目的和驅動力的。
- 系統設計滿足業務需求和流量現狀，選擇最熟悉的技術體系
- 業務需求增加和流量增加，修正架構中存在的問題，如單點問題，橫向擴展問題，性能無法滿足需求等，選擇社區中成熟的，團隊熟悉的合適的組件去解決問題。
- 當對整個架構進行修補無法滿足需求時，才需要重構和重寫的方式進行大的架構調整。
以淘寶爲例，當時在業務從0到1的階段是通過購買的方式快速搭建了系統。而後，隨着流昰的增長，淘寶做了一系列的技術改造來提升高併發處理能力，比如數據庫存儲引擎從 MyISAM 遷移到 InnoDB，數據庫做分庫分表，增加緩存，啓動中間件研發等。
