1 解決思想

業務發展必然帶來洪水般流量，為持續確定系統可靠穩定，我們也得會“大禹治水”。萬變不離其宗，目前主流其實方案都可歸類如下三種思想：

1.1 Scale-out

一種分治思想，采用叢集将流量分散于各伺服器。像資料庫一主多從、分庫分表、存儲分片都是其思想的實際方案展現。網上有個例子很生動，假設現在有1口鍋，可以一次給10人做飯。突然要給100人做飯，scale-out就是擴充到10口鍋來做飯

使用緩存來提高系統的性能，就好比水庫，抵禦了大部分流量沖擊，盡力保證下遊的平安。也就是1口鍋在人來之前做10次。

幾乎所有服務都會用到緩存，可謂是現實的萬金油。比如CPU的一級緩存、二級緩存、三級緩存，作業系統緩存（如windows的page.sys檔案），MyBatis的一級緩存，二級緩存等。

緩存主要是能夠顯著提升系統的通路性能，更好支援高并發場景的通路。

因為資料是放在磁盤持久化儲存的，而用的最多的就是普通磁盤。

普通磁盤的尋道時間大約10ms

CPU執行指令和記憶體尋址的時間都是ns級

從千兆網卡上讀取資料的時間是μs級

是以磁盤最慢，是以通常利用記憶體作為存儲緩存的媒體，才能提升性能。

有時未處理完成之前，可以讓請求先傳回，在資料準備好之後再通知請求方，即可在機關時間内處理更多請求。也就是 100人來了，讓大家先拿着碗兒等着，做好飯了再給大家一個個盛過去，而不要都擠死在鍋邊。

與之相反的是同步，同步調用代表調用方要阻塞等待被調用方法中的邏輯執行完成。這種方式下，當被調用方法響應時間較長時，會造成調用方長久的阻塞，在高并發下會造成整體系統性能下降甚至發生雪崩。

異步調用則相反，調用方不必等待方法邏輯執行完成就可傳回執行其他邏輯，在被調用方法執行完畢後再通過回調、事件通知等方式将結果回報給調用方。

異步在高并發系統中也是常客了，我們也很容易觀察到，比如訂高鐵票時，頁面會提示你系統正在排隊，其實就是系統在異步處理我們的訂票請求。因為在12306中查餘票、下單和更改餘票狀态等都是較耗時的操作，涉及多個系統間互相調用，如果還堅持同步，那高峰期你永遠别指望能下單成功。

采用異步的話，後端處理會把請求丢到MQ，同時快速響應使用者，通知其系統正在排隊處理，然後釋放出資源來處理更多請求。訂票請求處理完後，再通知使用者訂票成功或失敗。

處理邏輯後移到異步處理程式中，Web服務的壓力小了，資源占用的少了，自然就能接收更多的使用者訂票請求，系統承受高并發的能力也就提升了。

這其實就是解藕操作，訂單成交的消息需要保證的是準确性而不是實時性，是以就先放入 MQ，消息被消費的時候在進行業務的處理，這樣就可以提高并發性能。