隨着互聯網、移動互聯網、物聯網的普及，對於有一定規模的系統來說高併發設計是勢在必行的，本文來總結一下高併發設計的目標，首先看一下高併發的定義。
高併發定義
高併發是指系統在單位時間內處理更多的用戶併發請求，也就是承擔更大的流量，它是一切系統架構設計的背景和前提。每秒一次請求和每秒一萬次請求，兩種場景下分別做到毫秒級響應和五個九（99.999%）的可用性，設計難度和複雜度都不是一個量級的。
高併發設計的目標
- 高性能
- 高可用
- 可擴展
一、如何提升性能
性能優化原則
- 性能問題不能盲從，一定是問題導向
- 遵循二八原則，用20%的精力解決80%的性能問題，抓住主要矛盾，優化主要瓶頸點
- 要有數據支撐，縮短了多少響應時間，提高了多少吞吐量
- 優化過程是持續的，明確目標，制定優化方案，持續不斷地找到性能瓶頸，直到達到目標爲止
性能度量指標
- 一般來說，度量性能的指標是指系統接口的響應時間，單次的響應時間是沒有意義的，需要有一段時間內的特徵值
- 平均值：敏感度比較差
- 最大值：過於敏感
- 分位值：把一段時間內響應時間從小到大排序，假如有100個請求，排在第90位的就是90分位值，排除偶發情況外，能很好地反映這段時間的性能情況，分位值越大對慢請求的影響越敏感
- 響應時間控制在多少比較合適
- 200ms是第一個分界點，200ms之內用戶是感覺不到延遲的
- 1s是第二個分界點，1s之內用戶能感受到一些延遲，還是接受的，超過1s之後用戶有明顯的等待，等待時間越長用戶體驗越差，所以健康系統響應時間的99分位值應該控制在200ms以內，不超過1s的請求佔比要達到99.99%以上
性能優化思路
- 提高系統的處理核心數
多線程，增加系統的並行處理能力 - 縮短單次請求的響應時間
CPU密集型：選用更高效的算法或減少運算次數
IO密集型：大部分業務系統都屬於IO密集型，比如數據庫系統、緩存系統、Web系統，這些系統的瓶頸可能在內部也可能在依賴的其它系統，需要具體問題具體分析
二、怎樣做到高可用
- 成熟系統的可用性需要從系統設計和系統運維兩方面做保障，缺一不可
系統設計
- 無損方案
- 故障轉移Faliover
- 有損方案
- 超時控制
不讓請求一直保持，而是在經過一段時間後讓請求失敗，釋放資源給接下的請求 - 降級
保證核心服務的穩定而犧牲非核心服務的做法 - 限流
對併發請求進行限速來保護系統
系統運維
- 灰度發佈
按照一定比例逐步推到線上 - 故障演練
對系統進行一些破壞性的手段，觀察出現故障時系統的表現，從而發現潛在的可用性問題。故障演練是以系統可以抵禦一些異常爲前提的，如果系統還沒有做到這一點，需要另外搭建一套和線上一模一樣的測試環境來演練，避免對生產系統造成影響。 - 混沌工程
在線上系統隨機關閉節點來模擬故障，讓工程師瞭解在出現此類問題時會有什麼樣的影響
DevOps
- Dev：冗餘和取捨，冗餘指的是有備用節點，集羣來頂替出故障的服務，取捨指的是丟卒保車，保障主題服務安全
- Ops：注重如何避免故障的發生，關注變更管理以及如何做故障演練
三、如何讓系統易於擴展
- 數據庫、緩存、依賴的第三方、負載均衡、交換機帶寬都是系統擴展時需要考慮的因素
高可擴展性的設計思路
- 拆分是提升系統擴展性最重要的一個思路
- 存儲層的擴展性
- 存儲拆分首先考慮業務維度
- 長時間運行後，單一業務數據庫在容量和併發請求上會超過單機限制，此時可以對數據庫做水平拆分（分庫分表），不能隨意增加節點，一旦增加節點需要手動遷移數據，成本很高，基於長遠考慮需要一次性增加足夠多的節點以避免頻繁擴容
- 拆分後儘量不要用事物，分佈式事物兩階段提交的協調成本會隨着資源的擴展不斷提高，最終達到無法承受的程度
- 業務層的擴展性
可以從三個維度考慮業務層的拆分方案：業務維度、重要性維度、請求來源維度
- 把相同業務的服務拆分成單獨集羣
- 根據業務接口的重要程度，把業務分爲核心集羣和非核心集羣
- 根據接口調用方做不同業務集羣的拆分
總結
高併發設計是爲了使系統能應對大流量請求，設計方案需要考慮高性能、高可用、可擴展三個方面，優化之前需要有指標數據支撐，確立目標後，循序漸進，以解決系統中存在的問題爲目標，持續優化系統實現。