在我們搭建大型系統（使用者量）的時候併發是一個很頭疼的問題，如何設計好這個系統是一個很重要的問題。

1.瞬時併發

在平常併發量並不是很多，但是當比如搞活動的時候併發量突然猛增，這時候處理方式。

這個時候我們需要將所有的請求攔截下來（攔截器或其他方式），把請求資訊放到我們設定好的訊息佇列中，然後由訊息佇列來控制給伺服器灌入，避免同時大量請求直接進入伺服器，使伺服器掛掉。

但是這樣如果我們的訊息佇列滿了的話，那應該怎麼辦呢？

訊息佇列滿了，但是我們的請求不能丟掉，這時候我們需要額外的加一層訊息佇列的保障，保障當訊息佇列滿的時候，請求不丟失。

2.持續併發

即使在平常的日子併發量也很高，這個時候一臺伺服器已經滿足不了要求，需要搭建伺服器叢集。

說一下概念的問題：

叢集：指多個伺服器做相同的事情；

分散式：指多個伺服器做不同的步驟。

那這個時候我們的處理方案：

這個時候所有的請求全部交給nginx來分配給不同的伺服器。

nginx通過配置計算機ip和域名來分配，也可以分配權重。

但是這個時候我們來模擬一個登入的功能（token或session）

第一登入的時候，nginx分配到了第一臺伺服器上，登入資訊也存在了第一臺伺服器上。那麼第二次請求，把我的請求分配到了第二個服務上，第二個伺服器上沒有我的登入資訊，提示我登入。這個時候就出現了問題，那我們怎麼解決這個問題呢？

那我可以通過配置使同一個ip的請求都分配到同一個伺服器上來解決。

但是問題又來了，如果你使用的伺服器宕機了怎麼辦（使用的時候不只你一個人，很多人都在使用，不能影響使用者的使用）？

這個時候呢，需要額外的配置一個東西來儲存使用者的登入資訊（常用redis），這個時候不管分配到了哪個伺服器上，都通過訪問redis中的資料來進行驗證。

那這樣是不是就好了呢？不是的，還存在比如redis掛了怎麼辦？

像資料庫（sql,nosql）這樣存資料的東西，一旦掛了如果沒有預防方案，損失很大。通常採用主從同步的方式來預防這個問題。

當然像單個數據庫已經扛不住的情況，都可以採用叢集的方式來解決，採用資料庫叢集。

3.架構設計

先看一張架構圖

1.前臺網頁資源與後臺分離。

2.取消service模式，採用微服務方式，減少程式碼的重用。

外話：微服務的由來：加入我要開發兩個系統，在我開發第二個系統的時候，發現有90%的功能在第一個系統上開發過，這時候我就不回去重複開發，而會把原來的功能抽出來，整成介面，誰用呼叫介面就好。

4.rpc

RPC介紹

因為越來越多的微服務產生，很容出現一個問題。

比如：A開發了一套系統，有a功能，抽成了介面。B開發另外一套系統也用到了a功能，沒有跟A說，直接接到了a介面，這時候

C開發了一套系統也用到了a功能，也直接掉用a介面，看起來很方便。但是當B開發的系統開始搞活動，導致併發量猛增。直接把a功能的伺服器掛掉了。直接導致A系統也崩了。這時候老闆來找原因，誰也不說。最後A悲慘的背鍋。

RPC是一個提供微服務管理框架的遠端過程呼叫協議，他可以更好的管理微服務。

rpc中生產者是提供介面的一方，需要在管理平臺上進行註冊，註冊以後平臺會記錄這個服務的配置資訊（ip等），然後返回給服務，下次再呼叫的時候直接比對token就好。

然後平臺要對服務的伺服器進行心跳監控，防止伺服器宕機，其他應用還在使用該伺服器。

呼叫者需要再平臺進行註冊，記錄資訊。同樣返回一個token，呼叫者請求使用介面，平臺根據介面的併發量的決定是否同意呼叫。同意之後，呼叫者開始使用創造者的介面，但是每隔一定時間，呼叫者獲取輪詢一下伺服器的資訊，為了防止新增伺服器，而呼叫者不知道的情況。