相信每一位開發同學多多少少都想參與或負責一個高用戶、高訪問、高并發的系統吧。一來可以增加自己實際的項目經驗，有應對高并發場景的解決方案，二來是有個高并發的項目經驗無疑是自己簡歷的一個大大的加分項。

但是奈何很多人都沒有機會可以參與這樣的項目，本文從以下幾點介紹一下設計一個高流量高并發的系統需要經歷哪些步驟以及考慮哪些因素(文章中的不足之處還請大佬們多多指點)。

高流量高并發系統關注點

1、設計原則

1.1、系統設計原則

在設計一個系統之前，我們先要有一個統一且清晰的認知：不要想著一下就能設計出完美的系統，好的系統是迭代出來的。不要復雜化，要先解決核心問題。但是要有先行的規劃，對現有的問題有方案，對未來系統有預案。

在設計高并發的系統時要遵循以下幾個原則：

無狀態原則

什么是無狀態?服務器不保存狀態，對單次請求的處理不依賴別的請求就是無狀態，主要是為了在應對高并發時方便水平擴展。

拆分原則

在我們的系統體積過于龐大或者承載不了大量的請求時，就要考慮拆分系統，將復雜問題簡單化或將流量分散不同子系統分擔壓力。可以按照以下幾個維度進行拆分：

• 系統維度： 比如電商系統，我們可以拆分成商品、支付、優惠券多個子系統。
• 功能維度： 將系統按功能再次拆分。
• 讀寫維度： 按照讀寫比例將服務拆分成讀服務和寫服務。
• 模塊維度： 將系統按照基礎架構、消息隊列、分庫分表 、組件等模塊進行拆分維護。

服務化原則

當我們的系統被拆分的足夠大時，一旦發生故障靠人工來處理是非常耗時耗力。這個時候就可以通過注冊發現、限流、熔斷、降級等方案讓每個服務可以自己處理問題來幫助我們減少排障成本。

1.2、業務設計原則

在進行業務設計時要遵循一些最基本的原則比如：

防重原則

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

模塊復用原則

在業務中每個功能多多少少是有聯系的，在設計的時候模塊盡量要獨立，其他模塊直接調用即可，調用減少代碼的冗余。

可追溯原則

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

反饋原則

系統對用戶的響應應該是具體、詳細的，舉一個很簡單的例子，用戶登錄失敗后應該反饋給用戶的是“用戶名錯誤”或者“密碼錯誤”，而不是“登錄失敗”。

備份原則

做好代碼備份、數據備份以及人員備份。

2、客戶端優化

在高并發高流量的系統客戶端的優化是必不可少的，如果沒有做好客戶端的優化影響用戶體驗是一方面，有時候甚至是致命的。

這里分享下我之前慘痛的教訓：之前參與過一個秒殺的業務，就是因為前端的沒有做優化，大量用戶在刷新頁面時服務器的帶寬被打爆，頁面加載不出來，影響了系統的發展，這是非常致命的。主要原因還是沒有經驗，以為后端做好高并發抵抗就可以。

客戶端優化主要集中以下幾點：

資源下載

• 減少不必要傳輸：例如減少cookie使用，因為cookie 隨著請求發送而發送從而增加數據量。
• 減少數據量輸出：例如刪除JS無效注釋，一來可以減少體積，二來可以提高代碼安全。或者可以將文件壓縮后傳輸。
• 減少請求 ：將資源數目多、體積小、頻繁創建http請求的文件合并，比如JS合并、矢量圖 SVG。
• 轉移第三方：將請求轉移至第三方，例如oss。

資源緩存

常見的資源緩存就是圖片、樣式和腳本。有些場景可以利用客戶端的緩存幫助服務端分擔壓力，比如網約車中的預估價格，客戶端可以緩存計算規則并緩存，減少向服務端的請求。

資源解析

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

• 懶加載： 先加載基礎的，再根據用戶的操作進行局部加載。將原來一次性要加載的拆分成多次加載，減少下載數量和耗時。比如：樹節點、折疊面板、二級菜單等。
• 預加載： 當前頁面對下個頁面的解析、拉取資源。下面代碼作為參考

<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應用在客戶端——>服務端之前，能夠實時的根據網絡流量和各節點的連接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求導向離用戶最近的服務節點上，使用戶可以就近取得所需內容，解決網絡擁擠的狀況，提高用戶訪問網站的響應速度和成功率。我們可以通過CDN服務商購買CDN服務，綁定我們的域名，其他的事就不用我們管了。

借用一張網絡上的圖片幫助理解下

4、服務的集群

通常高并發系統都存在集群節點，為了抵抗大量的請求，也為了系統的高可用。根據業務場景利用負載策略將一個請求分發到集群中的某個計算節點。通過Nginx、LVS、Keepalived等集群組件可以輕松的實現這一功能。

依然是借用一張網絡上的圖片

5、服務端緩存

緩存的介入其實就是空間換時間，常見的緩存組件redis、memcache、guava都可以起到減少響應時間的作用，在高并發的項目中經常被使用到，適合讀多寫少、耗時長的查詢場景。但是會帶來開發人員學習、寫代碼、部署機器、維護的成本。在設計key時要有以下幾點認知：

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

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

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

6、數據庫優化

我們知道所有的業務數據最終都會落到數據庫，隨著數據量的增加會帶來響應時間的增加，以及系統的負載不斷上升，數據庫單點壓力會越來越大，這個時候對數據庫的優化就不單僅是冗余、反范式、索引，可以根據業務場景參考以下方案：

表分區

在mysql中一張表的數據對應一個ibd文件，當文件過大時查找數據就會變的很慢。表分區是將一張表按照hash、list、key等規則進行分流，在物理上將這一張表ibd文件分成多個文件，但是邏輯上還是一張表。訪問量不大，但是表數據很多的表，可以采用這種方式，這樣的好處就是查詢的數據在一個分區時會很快的查到。

分庫分表

分庫分表是真正的把一張表分布在不同的庫或多張表，在訪問量大的時候可以把一張表分多張表并且分布在不同的庫減少單個數據庫的壓力，提高并發。或者按照業務劃分進行分庫分表達到數據隔離的作用。但是這種方式往往會帶來分布式id、事務、join查詢等一系列問題，我們只能通過代碼層面來解決，無疑增加了復雜度。

讀寫分離

在讀多寫少的場景下我們可以利用shardingjdbc、mycat等開源框架或組件路由到寫庫或者讀庫實現讀寫分離。同樣讀寫分離也存在一定的問題，比如主從復制問題、時間差問題等，可以結合業務場景規避。

7、服務治理

在高并發的項目中，往往我們的后端服務是很龐大的，因為服務拆分所引發的如：服務調用、服務雪崩、節點故障問題，以及處理高并發請求的問題。如何解決這些問題，讓服務更穩定地運行，我們管它叫作服務治理。通常有以下幾種方案：

• 降級： 在高并發的請求下，如果服務資源不足，我們可以丟車保帥，將功能減弱保障核心業務。
• 熔斷： 通常服務間的調用可能會發生服務雪崩的情況，為了防止這種情況發生，我們為單個服務設置保險絲，當外部系統不能訪問后禁止調用。
• 限流： 根據資源或者服務的QPS、線程數情況限制請求量或資源量進行自我保護。
• 隔離： 隔離通常是為了達到不因某個資源異常而影響其他資源的正常使用。比如數據隔離(分庫)、機器隔離(重要的用戶單獨配置服務器)、機房隔離等。

總結

做好一個高流量高并發的系統，不論前端還是后端，過程中每一個步驟都是至關重要的。設計一個系統除了滿足功能性，還要考慮兼容性、易用性、可靠性、安全性、可維護性、可移植性等軟件質量。同時要對系統的吞吐量、并發數、平均響應時間等指標要完全掌握，在指標異常時可以快速做出決策避免一系列問題發生。