相信每一位開發(fā)同學(xué)多多少少都想?yún)⑴c或負(fù)責(zé)一個(gè)高用戶、高訪問、高并發(fā)的系統(tǒng)吧。一來可以增加自己實(shí)際的項(xiàng)目經(jīng)驗(yàn)，有應(yīng)對(duì)高并發(fā)場(chǎng)景的解決方案，二來是有個(gè)高并發(fā)的項(xiàng)目經(jīng)驗(yàn)無(wú)疑是自己簡(jiǎn)歷的一個(gè)大大的加分項(xiàng)。

但是奈何很多人都沒有機(jī)會(huì)可以參與這樣的項(xiàng)目，本文從以下幾點(diǎn)介紹一下設(shè)計(jì)一個(gè)高流量高并發(fā)的系統(tǒng)需要經(jīng)歷哪些步驟以及考慮哪些因素(文章中的不足之處還請(qǐng)大佬們多多指點(diǎn))。

高流量高并發(fā)系統(tǒng)關(guān)注點(diǎn)

1、設(shè)計(jì)原則

1.1、系統(tǒng)設(shè)計(jì)原則

在設(shè)計(jì)一個(gè)系統(tǒng)之前，我們先要有一個(gè)統(tǒng)一且清晰的認(rèn)知：不要想著一下就能設(shè)計(jì)出完美的系統(tǒng)，好的系統(tǒng)是迭代出來的。不要復(fù)雜化，要先解決核心問題。但是要有先行的規(guī)劃，對(duì)現(xiàn)有的問題有方案，對(duì)未來系統(tǒng)有預(yù)案。

在設(shè)計(jì)高并發(fā)的系統(tǒng)時(shí)要遵循以下幾個(gè)原則：

無(wú)狀態(tài)原則

什么是無(wú)狀態(tài)?服務(wù)器不保存狀態(tài)，對(duì)單次請(qǐng)求的處理不依賴別的請(qǐng)求就是無(wú)狀態(tài)，主要是為了在應(yīng)對(duì)高并發(fā)時(shí)方便水平擴(kuò)展。

拆分原則

在我們的系統(tǒng)體積過于龐大或者承載不了大量的請(qǐng)求時(shí)，就要考慮拆分系統(tǒng)，將復(fù)雜問題簡(jiǎn)單化或?qū)⒘髁糠稚⒉煌酉到y(tǒng)分擔(dān)壓力?？梢园凑找韵聨讉€(gè)維度進(jìn)行拆分：

• 系統(tǒng)維度： 比如電商系統(tǒng)，我們可以拆分成商品、支付、優(yōu)惠券多個(gè)子系統(tǒng)。
• 功能維度： 將系統(tǒng)按功能再次拆分。
• 讀寫維度： 按照讀寫比例將服務(wù)拆分成讀服務(wù)和寫服務(wù)。
• 模塊維度： 將系統(tǒng)按照基礎(chǔ)架構(gòu)、消息隊(duì)列、分庫(kù)分表 、組件等模塊進(jìn)行拆分維護(hù)。

服務(wù)化原則

當(dāng)我們的系統(tǒng)被拆分的足夠大時(shí)，一旦發(fā)生故障靠人工來處理是非常耗時(shí)耗力。這個(gè)時(shí)候就可以通過注冊(cè)發(fā)現(xiàn)、限流、熔斷、降級(jí)等方案讓每個(gè)服務(wù)可以自己處理問題來幫助我們減少排障成本。

1.2、業(yè)務(wù)設(shè)計(jì)原則

在進(jìn)行業(yè)務(wù)設(shè)計(jì)時(shí)要遵循一些最基本的原則比如：

防重原則

在某些場(chǎng)景下要防止用戶重復(fù)操作，例如：用戶注冊(cè)、用戶下單、用戶支付等。我們需要在客戶端和服務(wù)端有一些方案避免這種問題。

模塊復(fù)用原則

在業(yè)務(wù)中每個(gè)功能多多少少是有聯(lián)系的，在設(shè)計(jì)的時(shí)候模塊盡量要獨(dú)立，其他模塊直接調(diào)用即可，調(diào)用減少代碼的冗余。

可追溯原則

在程序的運(yùn)行中避免不了業(yè)務(wù)問題以及故障的發(fā)生，但是我們可以通過日志的方式快速定位問題，做到有據(jù)可查。

反饋原則

系統(tǒng)對(duì)用戶的響應(yīng)應(yīng)該是具體、詳細(xì)的，舉一個(gè)很簡(jiǎn)單的例子，用戶登錄失敗后應(yīng)該反饋給用戶的是“用戶名錯(cuò)誤”或者“密碼錯(cuò)誤”，而不是“登錄失敗”。

備份原則

做好代碼備份、數(shù)據(jù)備份以及人員備份。

2、客戶端優(yōu)化

在高并發(fā)高流量的系統(tǒng)客戶端的優(yōu)化是必不可少的，如果沒有做好客戶端的優(yōu)化影響用戶體驗(yàn)是一方面，有時(shí)候甚至是致命的。

這里分享下我之前慘痛的教訓(xùn)：之前參與過一個(gè)秒殺的業(yè)務(wù)，就是因?yàn)榍岸说臎]有做優(yōu)化，大量用戶在刷新頁(yè)面時(shí)服務(wù)器的帶寬被打爆，頁(yè)面加載不出來，影響了系統(tǒng)的發(fā)展，這是非常致命的。主要原因還是沒有經(jīng)驗(yàn)，以為后端做好高并發(fā)抵抗就可以。

客戶端優(yōu)化主要集中以下幾點(diǎn)：

資源下載

• 減少不必要傳輸：例如減少cookie使用，因?yàn)閏ookie 隨著請(qǐng)求發(fā)送而發(fā)送從而增加數(shù)據(jù)量。
• 減少數(shù)據(jù)量輸出：例如刪除JS無(wú)效注釋，一來可以減少體積，二來可以提高代碼安全?；蛘呖梢詫⑽募嚎s后傳輸。
• 減少請(qǐng)求 ：將資源數(shù)目多、體積小、頻繁創(chuàng)建http請(qǐng)求的文件合并，比如JS合并、矢量圖 SVG。
• 轉(zhuǎn)移第三方：將請(qǐng)求轉(zhuǎn)移至第三方，例如oss。

資源緩存

常見的資源緩存就是圖片、樣式和腳本。有些場(chǎng)景可以利用客戶端的緩存幫助服務(wù)端分擔(dān)壓力，比如網(wǎng)約車中的預(yù)估價(jià)格，客戶端可以緩存計(jì)算規(guī)則并緩存，減少向服務(wù)端的請(qǐng)求。

資源解析

我們知道頁(yè)面中資源解析的順序是從上到下，如果上面有改變下面也需要變動(dòng)，所以我們要縮小回流、重繪的范圍，比如虛擬dom。除此之外我們還可以利用懶加載和預(yù)加載進(jìn)行優(yōu)化：

• 懶加載： 先加載基礎(chǔ)的，再根據(jù)用戶的操作進(jìn)行局部加載。將原來一次性要加載的拆分成多次加載，減少下載數(shù)量和耗時(shí)。比如：樹節(jié)點(diǎn)、折疊面板、二級(jí)菜單等。
• 預(yù)加載： 當(dāng)前頁(yè)面對(duì)下個(gè)頁(yè)面的解析、拉取資源。下面代碼作為參考

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel='dns-prefetch" href="www.baidu.com" >
<link rel='preload" href="..js" >
<link rel='prefetch" href="..js" >

3、使用CDN

CDN應(yīng)用在客戶端——>服務(wù)端之前，能夠?qū)崟r(shí)的根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載情況以及到用戶的距離和響應(yīng)時(shí)間等綜合信息將用戶的請(qǐng)求導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上，使用戶可以就近取得所需內(nèi)容，解決網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度和成功率。我們可以通過CDN服務(wù)商購(gòu)買CDN服務(wù)，綁定我們的域名，其他的事就不用我們管了。

借用一張網(wǎng)絡(luò)上的圖片幫助理解下

4、服務(wù)的集群

通常高并發(fā)系統(tǒng)都存在集群節(jié)點(diǎn)，為了抵抗大量的請(qǐng)求，也為了系統(tǒng)的高可用。根據(jù)業(yè)務(wù)場(chǎng)景利用負(fù)載策略將一個(gè)請(qǐng)求分發(fā)到集群中的某個(gè)計(jì)算節(jié)點(diǎn)。通過Nginx、LVS、Keepalived等集群組件可以輕松的實(shí)現(xiàn)這一功能。

依然是借用一張網(wǎng)絡(luò)上的圖片

5、服務(wù)端緩存

緩存的介入其實(shí)就是空間換時(shí)間，常見的緩存組件redis、memcache、guava都可以起到減少響應(yīng)時(shí)間的作用，在高并發(fā)的項(xiàng)目中經(jīng)常被使用到，適合讀多寫少、耗時(shí)長(zhǎng)的查詢場(chǎng)景。但是會(huì)帶來開發(fā)人員學(xué)習(xí)、寫代碼、部署機(jī)器、維護(hù)的成本。在設(shè)計(jì)key時(shí)要有以下幾點(diǎn)認(rèn)知：

• 盡量避免沖突碰撞。
• sha-256沖突極低。
• 查詢key的速度取決于物理位置。

否則使用緩存的收益是非常低甚至沒有必要的。

當(dāng)然，緩存技術(shù)的引入也是可能會(huì)帶來一些列緩存問題，比如緩存擊穿、緩存穿透、緩存雪崩等，依然需要代碼層面去解決，在使用時(shí)需要注意這些問題。

6、數(shù)據(jù)庫(kù)優(yōu)化

我們知道所有的業(yè)務(wù)數(shù)據(jù)最終都會(huì)落到數(shù)據(jù)庫(kù)，隨著數(shù)據(jù)量的增加會(huì)帶來響應(yīng)時(shí)間的增加，以及系統(tǒng)的負(fù)載不斷上升，數(shù)據(jù)庫(kù)單點(diǎn)壓力會(huì)越來越大，這個(gè)時(shí)候?qū)?shù)據(jù)庫(kù)的優(yōu)化就不單僅是冗余、反范式、索引，可以根據(jù)業(yè)務(wù)場(chǎng)景參考以下方案：

表分區(qū)

在mysql中一張表的數(shù)據(jù)對(duì)應(yīng)一個(gè)ibd文件，當(dāng)文件過大時(shí)查找數(shù)據(jù)就會(huì)變的很慢。表分區(qū)是將一張表按照hash、list、key等規(guī)則進(jìn)行分流，在物理上將這一張表ibd文件分成多個(gè)文件，但是邏輯上還是一張表。訪問量不大，但是表數(shù)據(jù)很多的表，可以采用這種方式，這樣的好處就是查詢的數(shù)據(jù)在一個(gè)分區(qū)時(shí)會(huì)很快的查到。

分庫(kù)分表

分庫(kù)分表是真正的把一張表分布在不同的庫(kù)或多張表，在訪問量大的時(shí)候可以把一張表分多張表并且分布在不同的庫(kù)減少單個(gè)數(shù)據(jù)庫(kù)的壓力，提高并發(fā)?；蛘甙凑諛I(yè)務(wù)劃分進(jìn)行分庫(kù)分表達(dá)到數(shù)據(jù)隔離的作用。但是這種方式往往會(huì)帶來分布式id、事務(wù)、join查詢等一系列問題，我們只能通過代碼層面來解決，無(wú)疑增加了復(fù)雜度。

讀寫分離

在讀多寫少的場(chǎng)景下我們可以利用shardingjdbc、mycat等開源框架或組件路由到寫庫(kù)或者讀庫(kù)實(shí)現(xiàn)讀寫分離。同樣讀寫分離也存在一定的問題，比如主從復(fù)制問題、時(shí)間差問題等，可以結(jié)合業(yè)務(wù)場(chǎng)景規(guī)避。

7、服務(wù)治理

在高并發(fā)的項(xiàng)目中，往往我們的后端服務(wù)是很龐大的，因?yàn)榉?wù)拆分所引發(fā)的如：服務(wù)調(diào)用、服務(wù)雪崩、節(jié)點(diǎn)故障問題，以及處理高并發(fā)請(qǐng)求的問題。如何解決這些問題，讓服務(wù)更穩(wěn)定地運(yùn)行，我們管它叫作服務(wù)治理。通常有以下幾種方案：

• 降級(jí)： 在高并發(fā)的請(qǐng)求下，如果服務(wù)資源不足，我們可以丟車保帥，將功能減弱保障核心業(yè)務(wù)。
• 熔斷： 通常服務(wù)間的調(diào)用可能會(huì)發(fā)生服務(wù)雪崩的情況，為了防止這種情況發(fā)生，我們?yōu)閱蝹€(gè)服務(wù)設(shè)置保險(xiǎn)絲，當(dāng)外部系統(tǒng)不能訪問后禁止調(diào)用。
• 限流： 根據(jù)資源或者服務(wù)的QPS、線程數(shù)情況限制請(qǐng)求量或資源量進(jìn)行自我保護(hù)。
• 隔離： 隔離通常是為了達(dá)到不因某個(gè)資源異常而影響其他資源的正常使用。比如數(shù)據(jù)隔離(分庫(kù))、機(jī)器隔離(重要的用戶單獨(dú)配置服務(wù)器)、機(jī)房隔離等。

總結(jié)

做好一個(gè)高流量高并發(fā)的系統(tǒng)，不論前端還是后端，過程中每一個(gè)步驟都是至關(guān)重要的。設(shè)計(jì)一個(gè)系統(tǒng)除了滿足功能性，還要考慮兼容性、易用性、可靠性、安全性、可維護(hù)性、可移植性等軟件質(zhì)量。同時(shí)要對(duì)系統(tǒng)的吞吐量、并發(fā)數(shù)、平均響應(yīng)時(shí)間等指標(biāo)要完全掌握，在指標(biāo)異常時(shí)可以快速做出決策避免一系列問題發(fā)生。