透過前面的文章，已經把用於功能開發的 整體技術架構 基本搭建好了， 快取和非同步訊息架構也確定好了，是不是整體技術架構就可以了呢？

很顯然不是，仍然有很多缺失的部分，比如對於高併發和海量資料的處理， 這兩個基本上也算是目前實際應用當中的標配了，因此在高層架構設計階段， 同樣要對這樣通用的功能 進行架構和處理方案的設計。

先來看看高併發問題的處理思路。

一：認識高併發問題

所謂高併發指的是：在同時或極短時間內，有大量的請求到達服務端，每個請求都需要服務端耗費資源進行處理，並做出相應的反饋。

高併發問題的本質就是：資源的有限性，比如：頻寬、CPU、記憶體、IO等。

就是因為資源有限，我們不可能同時去處理並滿足這些大量的請求，從而帶來一系列的問題，統稱就是高併發的問題。

二：高併發解決思路

從服務端來解決高併發問題的話：

核心思想：分而治之——請求分流。

現在不是同時來了太多的請求嗎？我一臺伺服器肯定處理不過來啊，那我就開始分流，先增加伺服器數量，比如增加到10臺，然後把請求透過一定的演算法，分散到這10臺伺服器去處理。

這樣一來，每臺伺服器處理的量就下來了，從這臺伺服器的角度看，沒有什麼高併發，也沒有什麼大量請求，都在可支援的範圍內搞定。

三：基本的處理方式：

1：提高應用處理的效能

舉個例子，假設某個業務功能，現在需要1秒才能處理一個請求，那對於一個Web伺服器Tomcat來說，假定Tomcat設定了500個執行緒，這已經不少了，也就是1秒最多能完成500個請求處理。

如果這個時候，提高應用處理的效能，到0。1秒就能處理一個請求了，還是這個Tomcat，還是這個配置環境，差不多每秒能處理5000個請求了。

也就是應用處理的效能越高，同樣部署環境的情況下，應用支撐高併發的能力越強。

關於應用最佳化的內容非常多，每層、每種技術都有很多最佳化的方案和思路，這個我們可以另文再聊。

比如：前端靜態化、CDN、多級快取、分庫分表、SQL最佳化等，從表現層一直到資料層，可最佳化的地方特別多，這裡都籠統的稱之為提升應用處理效能，以應對系統的高併發。

2：叢集處理

就跟前面舉例一樣，如果應用的效能已經很難提升了，還是存在併發問題，怎麼辦呢？

那就採用叢集來處理，一臺伺服器搞不定，那就多來幾臺。

比如現在同時有1萬的併發請求過來，一臺伺服器每秒能搞定500個請求，那很簡單，增加伺服器到20臺，前面用Nginx等進行流量分發，是不是很容易就支撐到1萬請求了。

如果現在加到10萬的併發請求呢，這個時候，就可以採用多級叢集進行分流。比如ELB先分發到Nginx，這個時候Nginx也不是一個，假設來10個，每個Nginx後面再帶著20個Tomcat，先不考慮高可用什麼的，就先體會分而治之處理高併發的思想。

這樣一來，落到每個Nginx上的流量還是1萬，後面跟20個Tomcat，每個Tomcat還是隻需要負責每秒500個請求的處理。

當然這裡沒有去考慮更多配套的資源，比如資料庫是否能支援等問題。

3：非同步加叢集處理

如果透過叢集還是很難處理高併發的請求量，比如現在加到了100萬併發，這種特別是在搞一些大促活動的時候，容易出現這麼高的峰值併發量。

那該怎麼辦呢？可以考慮非同步加叢集的方式來處理。非同步在這裡起到削峰的作用，把請求處理延後。

當請求透過ELB過後，先導向多個Nginx，這些Nginx後面跟的不是具體的應用功能處理的服務，而是把接收到的請求，包裝成為訊息，扔到訊息系統裡面去，也就是做一個請求服務訊息傳送的叢集。

一般來說，訊息系統叢集的承載力是比較好的，而且是持久化的，不用太擔心效能問題。

然後再做一個從MQ裡面獲取訊息，再分發後端叢集來處理的，這麼一個訊息的消費者叢集。在這裡就可以自己控制速度，也可以控制是否要處理這個業務。

比如：活動只有前1000名成功，那麼這裡成功處理了1000個請求，剩下的訊息就可以丟棄，然後返回結果了。

高併發的處理有很多具體的方案，但大體都是這三大思路的具體化，或者是派生的思路，要應對高併發，思路總結起來就是：

1：應用自己跑快點， 就是提升應用的效能

2：還不行，就多來幾個， 就是採用叢集的方式，共同分擔高併發請求

3：還不行，那就延後處理，把處理時間拉長，單位時間內要處理的請求數量也就降下來了，是不是有點耍無賴

有關於高併發問題，我們就先聊到這裡。

如果你覺得本系列文章還不錯，能夠給你一些啟發和思考的話，請關注、點贊、收藏加轉發，讓更多的朋友加入到我們的行列，謝謝啦！

更多架構師之路乾貨文章，已在路上，稍後就到！