高併發學習筆記系列
高併發學習筆記--通用設計方法
從古至今，長江和黃河流域水患不斷，遠古時期，大禹曾拓寬河道，清除淤沙讓流水更加順暢；都江堰作爲史上最成功的的治水案例之一，用引流將岷江之水分流到多個支流中，以分擔水流壓力；三門峽和葛洲壩通過建造水庫將水引入水庫先存儲起來，然後再想辦法把水庫中的水緩緩地排出去，以此提高下游的抗洪能力。
而我們在應對高併發大流量時也會採用類似“抵禦洪水”的方案，歸納起來共有三種方法。
- Scale-out（橫向擴展）：分而治之是一種常見的高併發系統設計方法，採用分佈式部署的方式把流量分流開，讓每個服務器都承擔一部分併發和流量。
- 緩存：使用緩存來提高系統的性能，就好比用“拓寬河道”的方式抵抗高併發大流量的衝擊。
- 異步：在某些場景下，未處理完成之前，我們可以讓請求先返回，在數據準備好之後再通知請求方，這樣可以在單位時間內處理更多的請求。
Scale-up&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有哪些實現方式？
- 數據庫一主多從
- 分庫分表
- 存儲分片
使用緩存提升性能
Web 2.0 是緩存的時代，這一點毋庸置疑。緩存遍佈在系統設計的每個角落，從操作系統到瀏覽器，從數據庫到消息隊列，任何略微複雜的服務和組件中，你都可以看到緩存的影子。我們使用緩存的主要作用是提升系統的訪問性能，那麼在高併發的場景下，就可以支撐更多用戶的同時訪問。
衆所周知我們的數據最終是固化到磁盤上的，比如數據庫存儲、文件存儲。但是磁盤又是響應和性能最慢的介質。因此，我們通常使用以內存作爲存儲介質的緩存，以此提升性能。
異步處理
異步也是一種常見的高併發設計方法，我們在很多文章和演講中都能聽到這個名詞，與之共同出現的還有它的反義詞：同步。比如，分佈式服務框架 Dubbo 中有同步方法調用和異步方法調用，IO 模型中有同步 IO 和異步 IO。
什麼是同步，什麼是異步？
以方法調用爲例，同步調用代表調用方要阻塞等待被調用方法中的邏輯執行完成。這種方式下，當被調用方法響應時間較長時，會造成調用方長久的阻塞，在高併發下會造成整體系統性能下降甚至發生雪崩。
異步調用恰恰相反，調用方不需要等待方法邏輯執行完成就可以返回執行其他的邏輯，在被調用方法執行完畢後再通過回調、事件通知等方式將結果反饋給調用方。
異步調用在大規模高併發系統中被大量使用，比如我們熟知的 12306 網站。當我們訂票時，頁面會顯示系統正在排隊，這個提示就代表着系統在異步處理我們的訂票請求。在 12306 系統中查詢餘票、下單和更改餘票狀態都是比較耗時的操作，可能涉及多個內部系統的互相調用，如果是同步調用就會像 12306 剛剛上線時那樣，高峯期永遠不可能下單成功。
而採用異步的方式，後端處理時會把請求丟到消息隊列中，同時快速響應用戶，告訴用戶我們正在排隊處理，然後釋放出資源來處理更多的請求。訂票請求處理完之後，再通知用戶訂票成功或者失敗。
處理邏輯後移到異步處理程序中，Web 服務的壓力小了，資源佔用的少了，自然就能接收更多的用戶訂票請求，系統承受高併發的能力也就提升了。
