隨著網際網路、移動網際網路、物聯網的普及，對於有一定規模的系統來說高併發設計是勢在必行的，本文來總結一下高併發設計的目標，首先看一下高併發的定義。
高併發是指系統在單位時間內處理更多的使用者併發請求，也就是承擔更大的流量，它是一切系統架構設計的背景和前提。每秒一次請求和每秒一萬次請求，兩種場景下分別做到毫秒級響應和五個九（99.999%）的可用性，設計難度和複雜度都不是乙個量級的。
高效能高可用
可擴充套件
一、如何提公升效能
效能優化原則
效能問題不能盲從，一定是問題導向
遵循二八原則，用20%的精力解決80%的效能問題，抓住主要矛盾，優化主要瓶頸點
要有資料支撐，縮短了多少響應時間，提高了多少吞吐量
優化過程是持續的，明確目標，制定優化方案，持續不斷地找到效能瓶頸，直到達到目標為止
效能度量指標
平均值：敏感度比較差
最大值：過於敏感
分位值：把一段時間內響應時間從小到大排序，假如有100個請求，排在第90位的就是90分位值，排除偶發情況外，能很好地反映這段時間的效能情況，分位值越大對慢請求的影響越敏感
200ms是第乙個分界點，200ms之內使用者是感覺不到延遲的
1s是第二個分界點，1s之內使用者能感受到一些延遲，還是接受的，超過1s之後使用者有明顯的等待，等待時間越長使用者體驗越差，所以健康系統響應時間的99分位值應該控制在200ms以內，不超過1s的請求佔比要達到99.99%以上
效能優化思路
提高系統的處理核心數
多執行緒，增加系統的並行處理能力
縮短單次請求的響應時間
cpu密集型：選用更高效的演算法或減少運算次數
io密集型：大部分業務系統都屬於io密集型，比如資料庫系統、快取系統、web系統，這些系統的瓶頸可能在內部也可能在依賴的其它系統，需要具體問題具體分析
二、怎樣做到高可用
系統設計
故障轉移faliover
超時控制
不讓請求一直保持，而是在經過一段時間後讓請求失敗，釋放資源給接下的請求
降級保證核心服務的穩定而犧牲非核心服務的做法
限流對併發請求進行限速來保護系統
系統運維
灰度發布
按照一定比例逐步推到線上
故障演練
對系統進行一些破壞性的手段，觀察出現故障時系統的表現，從而發現潛在的可用性問題。故障演練是以系統可以抵禦一些異常為前提的，如果系統還沒有做到這一點，需要另外搭建一套和線上一模一樣的測試環境來演練，避免對生產系統造成影響。
devops
三、如何讓系統易於擴充套件
高可擴充套件性的設計思路
儲存層的擴充套件性
高併發設計是為了使系統能應對大流量請求，設計方案需要考慮高效能、高可用、可擴充套件三個方面，優化之前需要有指標資料支撐，確立目標後，循序漸進，以解決系統中存在的問題為目標，持續優化系統實現。
網際網路 高併發高可用
分布式 distributed 是指在多台不同的伺服器中部署不同的服務模組，通過遠端呼叫協同工作，對外提供服務。集群 cluster 是指在多台不同的伺服器中部署相同應用或服務模組，構成乙個集群，通過負載均衡裝置對外提供服務。load balancing，即負載均衡，是一種計算機技術，用來在多個計算...
網際網路系統架構演變簡史
隨著網際網路的發展，應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。網際網路系統架構也因此也不斷的演進 公升級 迭代。從單一應用，到垂直拆分，到分布式服務，到soa，以及現在火熱的微服務架構等，還有在google帶領下來勢洶湧的service mesh。作為一名合格的架構師，有必要對架構的前世...
移動網際網路系統架構的特點
一 併發性 相對於有線網際網路，移動網際網路的網速還是窄帶時期，大部分的網路訪問都屬於慢速連線。乙個請求占用的網路連線的時間比有線網際網路乙個請求占用網路連線的時間要長。在同等的伺服器端qps下，併發連線數要比有線網際網路模式的要高。雖然web伺服器的併發連線數問題非常容易通過增加機器來進行擴充套件...