如何設(shè)計一個高并發(fā)系統(tǒng)？
前言
最近有位粉絲問了我一個問題：如何設(shè)計一個高并發(fā)系統(tǒng)？
這是一個非常高頻的面試題，面試官可以從多個角度，考查技術(shù)的廣度和深度。
今天這篇文章跟大家一起聊聊高并發(fā)系統(tǒng)設(shè)計一些關(guān)鍵點，希望對你會有所幫助。
1、頁面靜態(tài)化
對于高并發(fā)系統(tǒng)的頁面功能，我們必須要做靜態(tài)化設(shè)計。
如果并發(fā)訪問系統(tǒng)的用戶非常多，每次用戶訪問頁面的時候，都通過服務(wù)器動態(tài)渲染，會導(dǎo)致服務(wù)端承受過大的壓力，而導(dǎo)致頁面無法正常加載的情況發(fā)生。
我們可以使用Freemarker或Velocity模板引擎，實現(xiàn)頁面靜態(tài)化功能。
以商城官網(wǎng)首頁為例，我們可以在Job中，每隔一段時間，查詢出所有需要在首頁展示的數(shù)據(jù)，匯總到一起，使用模板引擎生成到html文件當(dāng)中。
然后將該html文件，通過shell腳本，自動同步到前端頁面相關(guān)的服務(wù)器上。
2、CSDN加速
雖說頁面靜態(tài)化可以提升網(wǎng)站網(wǎng)頁的訪問速度，但還不夠，因為用戶分布在全國各地，有些人在北京，有些人在成都，有些人在深圳，地域相差很遠(yuǎn)，他們訪問網(wǎng)站的網(wǎng)速各不相同。
如何才能讓用戶最快訪問到活動頁面呢？
這就需要使用CDN，它的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。
使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率。
CDN加速的基本原理是：將網(wǎng)站的靜態(tài)內(nèi)容（如圖片、CSS、JavaScript文件等）復(fù)制并存儲到分布在全球各地的服務(wù)器節(jié)點上。
當(dāng)用戶請求訪問網(wǎng)站時，CDN系統(tǒng)會根據(jù)用戶的地理位置，自動將內(nèi)容分發(fā)給離用戶最近的服務(wù)器，從而實現(xiàn)快速訪問。
國內(nèi)常見的CDN提供商有阿里云CDN、騰訊云CDN、百度云加速等，它們提供了全球分布的節(jié)點服務(wù)器，為全球范圍內(nèi)的網(wǎng)站加速服務(wù)。
3、緩存
在高并發(fā)的系統(tǒng)中，緩存可以說是必不可少的技術(shù)之一。
目前緩存有兩種：
- 基于應(yīng)用服務(wù)器的內(nèi)存緩存，也就是我們說的二級緩存。
- 使用緩存中間件，比如：Redis、Memcached等，這種是分布式緩存。
這兩種緩存各有優(yōu)缺點。
二級緩存的性能更好，但因為是基于應(yīng)用服務(wù)器內(nèi)存的緩存，如果系統(tǒng)部署到了多個服務(wù)器節(jié)點，可能會存在數(shù)據(jù)不一致的情況。
而Redis或Memcached雖說性能上比不上二級緩存，但它們是分布式緩存，避免多個服務(wù)器節(jié)點數(shù)據(jù)不一致的問題。
緩存的用法一般是這樣的：
使用緩存之后，可以減輕訪問數(shù)據(jù)庫的壓力，顯著的提升系統(tǒng)的性能。
有些業(yè)務(wù)場景，甚至?xí)植际骄彺婧投壘彺嬉黄鹗褂谩?/p>
比如獲取商品分類數(shù)據(jù)，流程如下：
不過引入緩存，雖說給我們的系統(tǒng)性能帶來了提升，但同時也給我們帶來了一些新的問題，比如：《數(shù)據(jù)庫和緩存雙向數(shù)據(jù)庫一致性問題》、《緩存穿透、擊穿和雪崩問題》等。
我們在使用緩存時，一定要結(jié)合實際業(yè)務(wù)場景，切記不要為了緩存而緩存。
4、異步
有時候，我們在高并發(fā)系統(tǒng)當(dāng)中，某些接口的業(yè)務(wù)邏輯，沒必要都同步執(zhí)行。
比如有個用戶請求接口中，需要做業(yè)務(wù)操作，發(fā)站內(nèi)通知，和記錄操作日志。為了實現(xiàn)起來比較方便，通常我們會將這些邏輯放在接口中同步執(zhí)行，勢必會對接口性能造成一定的影響。
接口內(nèi)部流程圖如下：
這個接口表面上看起來沒有問題，但如果你仔細(xì)梳理一下業(yè)務(wù)邏輯，會發(fā)現(xiàn)只有業(yè)務(wù)操作才是核心邏輯，其他的功能都是非核心邏輯。
在這里有個原則就是：核心邏輯可以同步執(zhí)行，同步寫庫。非核心邏輯，可以異步執(zhí)行，異步寫庫。
上面這個例子中，發(fā)站內(nèi)通知和用戶操作日志功能，對實時性要求不高，即使晚點寫庫，用戶無非是晚點收到站內(nèi)通知，或者運營晚點看到用戶操作日志，對業(yè)務(wù)影響不大，所以完全可以異步處理。
通常異步主要有兩種：多線程 和 mq。
（1）線程池
使用線程池改造之后，接口邏輯如下：
發(fā)站內(nèi)通知和用戶操作日志功能，被提交到了兩個單獨的線程池中。
這樣接口中重點關(guān)注的是業(yè)務(wù)操作，把其他的邏輯交給線程異步執(zhí)行，這樣改造之后，讓接口性能瞬間提升了。
但使用線程池有個小問題就是：如果服務(wù)器重啟了，或者是需要被執(zhí)行的功能出現(xiàn)異常了，無法重試，會丟數(shù)據(jù)。
那么這個問題該怎么辦呢？
（2）mq
使用mq改造之后，接口邏輯如下：
對于發(fā)站內(nèi)通知和用戶操作日志功能，在接口中并沒真正實現(xiàn)，它只發(fā)送了mq消息到mq服務(wù)器。然后由mq消費者消費消息時，才真正的執(zhí)行這兩個功能。
這樣改造之后，接口性能同樣提升了，因為發(fā)送mq消息速度是很快的，我們只需關(guān)注業(yè)務(wù)操作的代碼即可。
5、多線程處理
在高并發(fā)系統(tǒng)當(dāng)中，用戶的請求量很大。
假如我們現(xiàn)在用mq處理業(yè)務(wù)邏輯。
一下子有大量的用戶請求，產(chǎn)生了大量的mq消息，保存到了mq服務(wù)器。
而mq的消費者，消費速度很慢。
可能會導(dǎo)致大量的消息積壓問題。
從而嚴(yán)重影響數(shù)據(jù)的實時性。
我們需要對消息的消費者做優(yōu)化。
最快的方式是使用多線程消費消息，比如：改成線程池消費消息。
當(dāng)然核心線程數(shù)、最大線程數(shù)、隊列大小 和 線程回收時間，一定要做成配置的，后面可以根據(jù)實際情況動態(tài)調(diào)整。
這樣改造之后，我們可以快速解決消息積壓問題。
除此之外，在很多數(shù)據(jù)導(dǎo)入場景，用多線程導(dǎo)入數(shù)據(jù)，可以提升效率。
溫馨提醒一下：使用多線程消費消息，可能會出現(xiàn)消息的順序問題。如果你的業(yè)務(wù)場景中，需要保證消息的順序，則要用其他的方式解決問題。感興趣的小伙伴，可以找我私聊。
6、分庫分表
有時候，高并發(fā)系統(tǒng)的吞吐量受限的不是別的，而是數(shù)據(jù)庫。
當(dāng)系統(tǒng)發(fā)展到一定的階段，用戶并發(fā)量大，會有大量的數(shù)據(jù)庫請求，需要占用大量的數(shù)據(jù)庫連接，同時會帶來磁盤IO的性能瓶頸問題。
此外，隨著用戶數(shù)量越來越多，產(chǎn)生的數(shù)據(jù)也越來越多，一張表有可能存不下。由于數(shù)據(jù)量太大，sql語句查詢數(shù)據(jù)時，即使走了索引也會非常耗時。
這時該怎么辦呢？
答：需要做分庫分表。
如下圖所示：
圖中將用戶庫拆分成了三個庫，每個庫都包含了四張用戶表。
如果有用戶請求過來的時候，先根據(jù)用戶id路由到其中一個用戶庫，然后再定位到某張表。
路由的算法挺多的：
- 根據(jù)id取模，比如：id=7，有4張表，則7%4=3，模為3，路由到用戶表3。
- 給id指定一個區(qū)間范圍，比如：id的值是0-10萬，則數(shù)據(jù)存在用戶表0，id的值是10-20萬，則數(shù)據(jù)存在用戶表1。
- 一致性hash算法
分庫分表主要有兩個方向：垂直和水平。
說實話垂直方向（即業(yè)務(wù)方向）更簡單。
在水平方向（即數(shù)據(jù)方向）上，分庫和分表的作用，其實是有區(qū)別的，不能混為一談。
- 分庫：是為了解決數(shù)據(jù)庫連接資源不足問題，和磁盤IO的性能瓶頸問題。
- 分表：是為了解決單表數(shù)據(jù)量太大，sql語句查詢數(shù)據(jù)時，即使走了索引也非常耗時問題。此外還可以解決消耗cpu資源問題。
- 分庫分表：可以解決 數(shù)據(jù)庫連接資源不足、磁盤IO的性能瓶頸、檢索數(shù)據(jù)耗時 和 消耗cpu資源等問題。
如果在有些業(yè)務(wù)場景中，用戶并發(fā)量很大，但是需要保存的數(shù)據(jù)量很少，這時可以只分庫，不分表。
如果在有些業(yè)務(wù)場景中，用戶并發(fā)量不大，但是需要保存的數(shù)量很多，這時可以只分表，不分庫。
如果在有些業(yè)務(wù)場景中，用戶并發(fā)量大，并且需要保存的數(shù)量也很多時，可以分庫分表。
關(guān)于分庫分表更詳細(xì)的內(nèi)容，可以看看我另一篇文章，里面講的更深入《阿里二面：為什么分庫分表？》
7、池化技術(shù)
其實不光是高并發(fā)系統(tǒng)，為了性能考慮，有些低并發(fā)的系統(tǒng)，也在使用池化技術(shù)，比如：數(shù)據(jù)庫連接池、線程池等。
池化技術(shù)是多例設(shè)計模式的一個體現(xiàn)。
我們都知道創(chuàng)建和銷毀數(shù)據(jù)庫連接是非常耗時耗資源的操作。
如果每次用戶請求，都需要創(chuàng)建一個新的數(shù)據(jù)庫連接，勢必會影響程序的性能。
為了提升性能，我們可以創(chuàng)建一批數(shù)據(jù)庫連接，保存到內(nèi)存中的某個集合中，緩存起來。
這樣的話，如果下次有需要用數(shù)據(jù)庫連接的時候，就能直接從集合中獲取，不用再額外創(chuàng)建數(shù)據(jù)庫連接，這樣處理將會給我們提升系統(tǒng)性能。
當(dāng)然用完之后，需要及時歸還。
目前常用的數(shù)據(jù)庫連接池有：Druid、C3P0、hikari和DBCP等。
8、讀寫分離
不知道你有沒有聽說過二八原則，在一個系統(tǒng)當(dāng)中可能有80%是讀數(shù)據(jù)請求，另外20%是寫數(shù)據(jù)請求。
不過這個比例也不是絕對的。
我想告訴大家的是，一般的系統(tǒng)讀數(shù)據(jù)請求會遠(yuǎn)遠(yuǎn)大于寫數(shù)據(jù)請求。
如果讀數(shù)據(jù)請求和寫數(shù)據(jù)請求，都訪問同一個數(shù)據(jù)庫，可能會相互搶占數(shù)據(jù)庫連接，相互影響。
我們都知道，一個數(shù)據(jù)庫的數(shù)據(jù)庫連接數(shù)量是有限，是非常寶貴的資源，不能因為讀數(shù)據(jù)請求，影響到寫數(shù)據(jù)請求吧？
這就需要對數(shù)據(jù)庫做讀寫分離了。
于是，就出現(xiàn)了主從讀寫分離架構(gòu)：
考慮剛開始用戶量還沒那么大，選擇的是一主一從的架構(gòu)，也就是常說的一個master，一個slave。
所有的寫數(shù)據(jù)請求，都指向主庫。一旦主庫寫完數(shù)據(jù)之后，立馬異步同步給從庫。這樣所有的讀數(shù)據(jù)請求，就能及時從從庫中獲取到數(shù)據(jù)了（除非網(wǎng)絡(luò)有延遲）。
但這里有個問題就是：如果用戶量確實有些大，如果master掛了，升級slave為master，將所有讀寫請求都指向新master。
但此時，如果這個新master根本扛不住所有的讀寫請求，該怎么辦？
這就需要一主多從的架構(gòu)了：
上圖中我列的是一主兩從，如果master掛了，可以選擇從庫1或從庫2中的一個，升級為新master。假如我們在這里升級從庫1為新master，則原來的從庫2就變成了新master的的slave了。
調(diào)整之后的架構(gòu)圖如下：
這樣就能解決上面的問題了。
除此之外，如果查詢請求量再增大，我們還可以將架構(gòu)升級為一主三從、一主四從...一主N從等。
9、索引
在高并發(fā)的系統(tǒng)當(dāng)中，用戶經(jīng)常需要查詢數(shù)據(jù)，對數(shù)據(jù)庫增加索引，是必不可少的一個環(huán)節(jié)。
尤其是表中數(shù)據(jù)非常多時，加了索引，跟沒加索引，執(zhí)行同一條sql語句，查詢相同的數(shù)據(jù)，耗時可能會相差N個數(shù)量級。
雖說索引能夠提升SQL語句的查詢速度，但索引也不是越多越好。
在insert數(shù)據(jù)時，需要給索引分配額外的資源，對insert的性能有一定的損耗。
我們要根據(jù)實際業(yè)務(wù)場景來決定創(chuàng)建哪些索引，索引少了，影響查詢速度，索引多了，影響寫入速度。
很多時候，我們需要經(jīng)常對索引做優(yōu)化。
- 可以將多個單個索引，改成一個聯(lián)合索引。
- 刪除不要索引。
- 使用explain關(guān)鍵字，查詢SQL語句的執(zhí)行計劃，看看哪些走了索引，哪些沒有走索引。
- 要注意索引失效的一些場景。
- 必要時可以使用force index來強(qiáng)制查詢sql走某個索引。
10、批處理
有時候，我們需要從指定的用戶集合中，查詢出有哪些是在數(shù)據(jù)庫中已經(jīng)存在的。
實現(xiàn)代碼可以這樣寫：
public List<User> queryUser(List<User> searchList) {
if (CollectionUtils.isEmpty(searchList)) {
return Collections.emptyList();
}
List<User> result = Lists.newArrayList();
searchList.forEach(user -> result.add(userMapper.getUserById(user.getId())));
return result;
}這里如果有50個用戶，則需要循環(huán)50次，去查詢數(shù)據(jù)庫。我們都知道，每查詢一次數(shù)據(jù)庫，就是一次遠(yuǎn)程調(diào)用。
如果查詢50次數(shù)據(jù)庫，就有50次遠(yuǎn)程調(diào)用，這是非常耗時的操作。
那么，我們?nèi)绾蝺?yōu)化呢？
答：批處理。
具體代碼如下：
public List<User> queryUser(List<User> searchList) {
if (CollectionUtils.isEmpty(searchList)) {
return Collections.emptyList();
}
List<Long> ids = searchList.stream().map(User::getId).collect(Collectors.toList());
return userMapper.getUserByIds(ids);
}提供一個根據(jù)用戶id集合批量查詢用戶的接口，只遠(yuǎn)程調(diào)用一次，就能查詢出所有的數(shù)據(jù)。
這里有個需要注意的地方是：id集合的大小要做限制，最好一次不要請求太多的數(shù)據(jù)。要根據(jù)實際情況而定，建議控制每次請求的記錄條數(shù)在500以內(nèi)。
11、集群
系統(tǒng)部署的服務(wù)器節(jié)點，可能會down機(jī)，比如：服務(wù)器的磁盤壞了，或者操作系統(tǒng)出現(xiàn)內(nèi)存不足問題。
為了保證系統(tǒng)的高可用，我們需要部署多個節(jié)點，構(gòu)成一個集群，防止因為部分服務(wù)器節(jié)點掛了，導(dǎo)致系統(tǒng)的整個服務(wù)不可用的情況發(fā)生。
集群有很多種：
- 應(yīng)用服務(wù)器集群
- 數(shù)據(jù)庫集群
- 中間件集群
- 文件服務(wù)器集群
我們以中間件Redis為例。
在高并發(fā)系統(tǒng)中，用戶的數(shù)據(jù)量非常龐大時，比如用戶的緩存數(shù)據(jù)總共大小有40G，一個服務(wù)器節(jié)點只有16G的內(nèi)存。
這樣需要部署3臺服務(wù)器節(jié)點。
該業(yè)務(wù)場景，使用普通的master/slave模式，或者使用哨兵模式都行不通。
40G的數(shù)據(jù)，不能只保存到一臺服務(wù)器節(jié)點，需要均分到3個master服務(wù)器節(jié)點上，一個master服務(wù)器節(jié)點保存13.3G的數(shù)據(jù)。
當(dāng)有用戶請求過來的時候，先經(jīng)過路由，根據(jù)用戶的id或者ip，每次都訪問指定的服務(wù)器節(jié)點。
這用就構(gòu)成了一個集群。
但這樣有風(fēng)險，為了防止其中一個master服務(wù)器節(jié)點掛掉，導(dǎo)致部分用戶的緩存訪問不了，還需要對數(shù)據(jù)做備份。
這樣每一個master，都需要有一個slave，做數(shù)據(jù)備份。
如果master掛了，可以將slave升級為新的master，而不影響用戶的正常使用。
12、負(fù)載均衡
如果我們的系統(tǒng)部署到了多臺服務(wù)器節(jié)點。那么哪些用戶的請求，訪問節(jié)點a，哪些用戶的請求，訪問節(jié)點b，哪些用戶的請求，訪問節(jié)點c？
我們需要某種機(jī)制，將用戶的請求，轉(zhuǎn)發(fā)到具體的服務(wù)器節(jié)點上。
這就需要使用負(fù)載均衡機(jī)制了。
在linux下有Nginx、LVS、Haproxy等服務(wù)可以提供負(fù)載均衡服務(wù)。
在SpringCloud微服務(wù)架構(gòu)中，大部分使用的負(fù)載均衡組件就是Ribbon、OpenFegin或SpringCloud Loadbalancer。
硬件方面，可以使用F5實現(xiàn)負(fù)載均衡。它可以基于交換機(jī)實現(xiàn)負(fù)載均衡，性能更好，但是價格更貴一些。
常用的負(fù)載均衡策略有：
- 輪詢：每個請求按時間順序逐一分配到不同的服務(wù)器節(jié)點，如果服務(wù)器節(jié)點down掉，能自動剔除。
- weight權(quán)重：weight代表權(quán)重默認(rèn)為1，權(quán)重越高，服務(wù)器節(jié)點被分配到的概率越大。weight和訪問比率成正比，用于服務(wù)器節(jié)點性能不均的情況。
- ip hash：每個請求按訪問ip的hash結(jié)果分配, 這樣每個訪客固定訪問同一個服務(wù)器節(jié)點，它是解訣Session共享的問題的解決方案之一。
- 最少連接數(shù)：把請求轉(zhuǎn)發(fā)給連接數(shù)較少的服務(wù)器節(jié)點。輪詢算法是把請求平均的轉(zhuǎn)發(fā)給各個服務(wù)器節(jié)點，使它們的負(fù)載大致相同；但有些請求占用的時間很長，會導(dǎo)致其所在的服務(wù)器節(jié)點負(fù)載較高。這時least_conn方式就可以達(dá)到更好的負(fù)載均衡效果。
- 最短響應(yīng)時間：按服務(wù)器節(jié)點的響應(yīng)時間來分配請求，響應(yīng)時間短的服務(wù)器節(jié)點優(yōu)先被分配。
當(dāng)然還有其他的策略，在這里就不給大家一一介紹了。
13、限流
對于高并發(fā)系統(tǒng)，為了保證系統(tǒng)的穩(wěn)定性，需要對用戶的請求量做限流。
特別是秒殺系統(tǒng)中，如果不做任何限制，絕大部分商品可能是被機(jī)器搶到，而非正常的用戶，有點不太公平。
所以，我們有必要識別這些非法請求，做一些限制。那么，我們該如何現(xiàn)在這些非法請求呢？
目前有兩種常用的限流方式：
- 基于nginx限流
- 基于redis限流
（1）對同一用戶限流
為了防止某個用戶，請求接口次數(shù)過于頻繁，可以只針對該用戶做限制。
限制同一個用戶id，比如每分鐘只能請求5次接口。
（2）對同一ip限流
有時候只對某個用戶限流是不夠的，有些高手可以模擬多個用戶請求，這種nginx就沒法識別了。
這時需要加同一ip限流功能。
限制同一個ip，比如每分鐘只能請求5次接口。
但這種限流方式可能會有誤殺的情況，比如同一個公司或網(wǎng)吧的出口ip是相同的，如果里面有多個正常用戶同時發(fā)起請求，有些用戶可能會被限制住。
（3）對接口限流
別以為限制了用戶和ip就萬事大吉，有些高手甚至可以使用代理，每次都請求都換一個ip。
這時可以限制請求的接口總次數(shù)。
在高并發(fā)場景下，這種限制對于系統(tǒng)的穩(wěn)定性是非常有必要的。但可能由于有些非法請求次數(shù)太多，達(dá)到了該接口的請求上限，而影響其他的正常用戶訪問該接口。看起來有點得不償失。
（4）加驗證碼
相對于上面三種方式，加驗證碼的方式可能更精準(zhǔn)一些，同樣能限制用戶的訪問頻次，但好處是不會存在誤殺的情況。
通常情況下，用戶在請求之前，需要先輸入驗證碼。用戶發(fā)起請求之后，服務(wù)端會去校驗該驗證碼是否正確。只有正確才允許進(jìn)行下一步操作，否則直接返回，并且提示驗證碼錯誤。
此外，驗證碼一般是一次性的，同一個驗證碼只允許使用一次，不允許重復(fù)使用。
普通驗證碼，由于生成的數(shù)字或者圖案比較簡單，可能會被破解。優(yōu)點是生成速度比較快，缺點是有安全隱患。
還有一個驗證碼叫做：移動滑塊，它生成速度比較慢，但比較安全，是目前各大互聯(lián)網(wǎng)公司的首選。
14、服務(wù)降級
前面已經(jīng)說過，對于高并發(fā)系統(tǒng)，為了保證系統(tǒng)的穩(wěn)定性，需要做限流。
但光做限流還不夠。
我們需要合理利用服務(wù)器資源，保留核心的功能，將部分非核心的功能，我們可以選擇屏蔽或者下線掉。
我們需要做服務(wù)降級。
我們在設(shè)計高并發(fā)系統(tǒng)時，可以預(yù)留一些服務(wù)降級的開關(guān)。
比如在秒殺系統(tǒng)中，核心的功能是商品的秒殺，對于商品的評論功能，可以暫時屏蔽掉。
在服務(wù)端的分布式配置中心，比如：apollo中，可以增加一個開關(guān)，配置是否展示評論功能，默認(rèn)是true。
前端頁面通過服務(wù)器的接口，獲取到該配置參數(shù)。
如果需要暫時屏蔽商品評論功能，可以將apollo中的參數(shù)設(shè)置成false。
此外，我們在設(shè)計高并發(fā)系統(tǒng)時，還可以預(yù)留一些兜底方案。
比如某個分類查詢接口，要從redis中獲取分類數(shù)據(jù)，返回給用戶。但如果那一條redis掛了，則查詢數(shù)據(jù)失敗。
這時候，我們可以增加一個兜底方案。
如果從redis中獲取不到數(shù)據(jù)，則從apollo中獲取一份默認(rèn)的分類數(shù)據(jù)。
目前使用較多的熔斷降級中間件是：Hystrix 和 Sentinel。
- Hystrix是Netflix開源的熔斷降級組件。
- Sentinel是阿里中間件團(tuán)隊開源的一款不光具有熔斷降級功能，同時還支持系統(tǒng)負(fù)載保護(hù)的組件。
二者的區(qū)別如下圖所示：
15、故障轉(zhuǎn)移
在高并發(fā)的系統(tǒng)當(dāng)中，同一時間有大量的用戶訪問系統(tǒng)。
如果某一個應(yīng)用服務(wù)器節(jié)點處于假死狀態(tài)，比如CPU使用率100%了，用戶的請求沒辦法及時處理，導(dǎo)致大量用戶出現(xiàn)請求超時的情況。
如果這種情況下，不做任何處理，可能會影響系統(tǒng)中部分用戶的正常使用。
這時我們需要建立故障轉(zhuǎn)移機(jī)制。
當(dāng)檢測到經(jīng)常接口超時，或者CPU打滿，或者內(nèi)存溢出的情況，能夠自動重啟那臺服務(wù)器節(jié)點上的應(yīng)用。
在SpringCloud微服務(wù)當(dāng)中，可以使用Ribbon做負(fù)載均衡器。
Ribbon是Spring Cloud中的一個負(fù)載均衡器組件，它可以檢測服務(wù)的可用性，并根據(jù)一定規(guī)則將請求分發(fā)至不同的服務(wù)節(jié)點。在使用Ribbon時，需要注意以下幾個方面：
- 設(shè)置請求超時時間，當(dāng)請求超時時，Ribbon會自動將請求轉(zhuǎn)發(fā)到其他可用的服務(wù)上。
- 設(shè)置服務(wù)的健康檢查，Ribbon會自動檢測服務(wù)的可用性，并將請求轉(zhuǎn)發(fā)至可用的服務(wù)上。
此外，還需要使用Hystrix做熔斷處理。
Hystrix是SpringCloud中的一個熔斷器組件，它可以自動地監(jiān)測所有通過它調(diào)用的服務(wù)，并在服務(wù)出現(xiàn)故障時自動切換到備用服務(wù)。在使用Hystrix時，需要注意以下幾個方面：
- 設(shè)置斷路器的閾值，當(dāng)故障率超過一定閾值后，斷路器會自動切換到備用服務(wù)上。
- 設(shè)置服務(wù)的超時時間，如果服務(wù)在指定的時間內(nèi)無法返回結(jié)果，斷路器會自動切換到備用服務(wù)上。到其他的能夠正常使用的服務(wù)器節(jié)點上。
16、異地多活
有些高并發(fā)系統(tǒng)，為了保證系統(tǒng)的穩(wěn)定性，不只部署在一個機(jī)房當(dāng)中。
為了防止機(jī)房斷電，或者某些不可逆的因素，比如：發(fā)生地震，導(dǎo)致機(jī)房掛了。
需要把系統(tǒng)部署到多個機(jī)房。
我們之前的游戲登錄系統(tǒng)，就部署到了深圳、天津和成都，這三個機(jī)房。
這三個機(jī)房都有用戶的流量，其中深圳機(jī)房占了40%，天津機(jī)房占了30%，成都機(jī)房占了30%。
如果其中的某個機(jī)房突然掛了，流量會被自動分配到另外兩個機(jī)房當(dāng)中，不會影響用戶的正常使用。
這就需要使用異地多活架構(gòu)了。
用戶請求先經(jīng)過第三方的DNS服務(wù)器解析，然后該用戶請求到達(dá)路由服務(wù)器，部署在云服務(wù)器上。
路由服務(wù)器，根據(jù)一定的算法，會將該用戶請求分配到具體的機(jī)房。
異地多活的難度是多個機(jī)房需要做數(shù)據(jù)同步，如何保證數(shù)據(jù)的一致性？
17、壓測
高并發(fā)系統(tǒng)，在上線之前，必須要做的一件事是做壓力測試。
我們先要預(yù)估一下生產(chǎn)環(huán)境的請求量，然后對系統(tǒng)做壓力測試，之后評估系統(tǒng)需要部署多少個服務(wù)器節(jié)點。
比如預(yù)估有10000的qps，一個服務(wù)器節(jié)點最大支持1000pqs，這樣我們需要部署10個服務(wù)器節(jié)點。
但假如只部署10個服務(wù)器節(jié)點，萬一突增了一些新的用戶請求，服務(wù)器可能會扛不住壓力。
因此，部署的服務(wù)器節(jié)點，需要把預(yù)估用戶請求量的多一些，比如：按3倍的用戶請求量來計算。
這樣我們需要部署30個服務(wù)器節(jié)點。
壓力測試的結(jié)果跟環(huán)境有關(guān)，在dev環(huán)境或者test環(huán)境，只能壓測一個大概的趨勢。
想要更真實的數(shù)據(jù)，我們需要在pre環(huán)境，或者跟生產(chǎn)環(huán)境相同配置的專門的壓測環(huán)境中，進(jìn)行壓力測試。
目前市面上做壓力測試的工具有很多，比如開源的有：Jemter、LoaderRunnder、Locust等等。
收費的有：阿里自研的云壓測工具PTS。
18、監(jiān)控
為了出現(xiàn)系統(tǒng)或者SQL問題時，能夠讓我們及時發(fā)現(xiàn)，我們需要對系統(tǒng)做監(jiān)控。
目前業(yè)界使用比較多的開源監(jiān)控系統(tǒng)是：Prometheus。
它提供了 監(jiān)控 和 預(yù)警 的功能。
架構(gòu)圖如下：
我們可以用它監(jiān)控如下信息：
- 接口響應(yīng)時間
- 調(diào)用第三方服務(wù)耗時
- 慢查詢sql耗時
- cpu使用情況
- 內(nèi)存使用情況
- 磁盤使用情況
- 數(shù)據(jù)庫使用情況
等等。。。
它的界面大概長這樣子：
可以看到mysql當(dāng)前qps，活躍線程數(shù)，連接數(shù)，緩存池的大小等信息。
如果發(fā)現(xiàn)數(shù)據(jù)量連接池占用太多，對接口的性能肯定會有影響。
這時可能是代碼中開啟了連接忘了關(guān)，或者并發(fā)量太大了導(dǎo)致的，需要做進(jìn)一步排查和系統(tǒng)優(yōu)化。
截圖中只是它一小部分功能，如果你想了解更多功能，可以訪問Prometheus的官網(wǎng)：https://prometheus.io/
其實，高并發(fā)的系統(tǒng)中，還需要考慮安全問題，比如：
- 遇到用戶不斷變化ip刷接口怎辦？
- 遇到用戶大量訪問緩存中不存在的數(shù)據(jù)，導(dǎo)致緩存雪崩怎么辦？
- 如果用戶發(fā)起ddos攻擊怎么辦？
- 用戶并發(fā)量突增，導(dǎo)致服務(wù)器扛不住了，如何動態(tài)擴(kuò)容？
