1、什麼是高併發
高併發是網際網路分布式系統架構設計中必須考慮的因素之一，就是通過設計保證系統可以並行處理很多請求。
4、常見的問題
（1）對資料化的指標沒有概念。
（2）設計了一些方案，但是細節掌握不透徹。
（3）理解片面，把高併發設計等同於效能優化。
（4）掌握大方案，卻忽視最基本的東西。
高併發系統設計的目標
高併發系統設計的目標有三個：高效能、高可用，以及高可擴充套件。
1、高效能：效能體現了系統的並行處理能力，在有限的硬體投入下，提高效能意味著節省成本，提高效能使用者體驗。
2、高可用：系統可以正常服務的時間。
3、高擴充套件：系統的擴充套件能力，流量高峰時能否在短時間內完成擴容，更平穩地承接峰值流量。
這3個目標它們互相關聯、也會相互影響。
比如說：考慮系統的擴充套件能力，會將服務設計成無狀態的，這種集群設計保證了高擴充套件性，其實也間接提公升了系統的效能和可用性。
再比如說：為了保證可用性，通常會對服務介面進行超時設定，以防大量執行緒阻塞在慢請求上造成系統雪崩，那超時時間設定成多少合理呢？一般，我們會參考依賴服務的效能表現進行設定。
可擴充套件性：面對突發流量，不可能臨時改造架構，最快的方式就是增加機器來線性提高系統的處理能力。對於業務集群或者基礎元件來說，擴充套件性 = 效能提公升比例 / 機器增加比例，理想的擴充套件能力是：資源增加幾倍，效能提公升幾倍。通常來說，擴充套件能力要維持在70%以上。但是從高併發系統的整體架構角度來看，擴充套件的目標不僅僅是把服務設計成無狀態就行了，因為當流量增加10倍，業務服務可以快速擴容10倍，但是資料庫可能就成為了新的瓶頸。像mysql這種有狀態的儲存服務通常是擴充套件的技術難點，如果架構上沒提前做好規劃（垂直和水平拆分），就會涉及到大量資料的遷移。因此，高擴充套件性需要考慮：服務集群、資料庫、快取和訊息佇列等中介軟體、負載均衡、頻寬、依賴的第三方等，當併發達到某乙個量級後，上述每個因素都可能成為擴充套件的瓶頸點。
高併發的實踐方案：通用的設計方法主要是從「縱向」和「橫向」兩個維度出發，俗稱高併發處理的兩板斧：縱向擴充套件和橫向擴充套件。
縱向擴充套件（scale-up）：它的目標是提公升單機的處理能力，方案又包括：
1、提公升單機的硬體效能：通過增加記憶體、cpu核數、儲存容量、或者將磁碟公升級成ssd等堆硬體的方式來提公升。
2、提公升單機的軟體效能：使用快取減少io次數，使用併發或者非同步的方式增加吞吐量。
橫向擴充套件（scale-out）：單機效能總會存在極限，所以最終還需要引入橫向擴充套件，通過集群部署以進一步提高併發處理能力，又包括以下2個方向：
1、做好分層架構：這是橫向擴充套件的提前，因為高併發系統往往業務複雜，通過分層處理可以簡化複雜問題，更容易做到橫向擴充套件。真實的高併發系統架構會做動靜分離並引入cdn，反向**層可以是lvs+nginx，web層可以是統一的api閘道器，業務服務層可進一步按垂直業務做微服務化，儲存層可以是各種異構資料庫。
2、各層進行水平擴充套件：無狀態水平擴容，有狀態做分片路由。業務集群通常能設計成無狀態的，而資料庫和快取往往是有狀態的，因此需要設計分割槽鍵做好儲存分片，當然也可以通過主從同步、讀寫分離的方案提公升讀效能。
高效能的方案: 集群部署，通過負載均衡減輕單機壓力。多級快取，包括靜態資料使用cdn、本地快取、分布式快取等，以及對快取場景中的熱點key、快取穿透、快取併發、資料一致性等問題的處理。分庫分表和索引優化，以及借助搜尋引擎解決複雜查詢問題。非同步化，將次要流程通過多執行緒、mq、甚至延時任務進行非同步處理。限流，需要先考慮業務是否允許限流（比如秒殺場景是允許的），包括前端限流、nginx接入層的限流、服務端的限流。對流量進行削峰填谷，通過mq承接流量。併發處理、預計算等。快取預熱，通過非同步任務提前預熱資料到本地快取或者分布式快取中。減少io次數，比如資料庫和快取的批量讀寫、rpc的批量介面支援、或者通過冗餘資料的方式去掉rpc呼叫。減少io時的資料報大小，包括採用輕量級的通訊協議、合適的資料結構、去掉介面中的多餘字段、減少快取key的大小、壓縮快取value等。程式邏輯優化，採用更高效的演算法。各種池化技術的使用和池大小的設定。鎖選擇，讀多寫少的場景用樂觀鎖，或者考慮通過分段鎖的方式減少鎖衝突。
從計算和 io 兩個維度考慮所有可能的優化點，需要有配套的監控系統實時了解當前的效能表現，並支撐進行效能瓶頸分析，遵循二八原則，抓主要問題進行優化。
高可用的方案：對等節點的故障轉移，nginx和服務治理框架均支援乙個節點失敗後訪問另乙個節點。非對等節點的故障轉移，通過心跳檢測並實施主備切換（比如redis的哨兵模式或者集群模式、mysql的主從切換等）。介面層面的超時設定、重試策略和冪等設計。熔斷降級處理：保證核心服務，犧牲非核心服務，必要時進行熔斷；或者核心鏈路出問題時，有備選鏈路。限流處理：對超過系統處理能力的請求直接拒絕或者返回錯誤碼。mq場景的訊息可靠性保證。灰度發布，能支援按機器維度進行小流量部署，觀察系統日誌和業務指標，等執行平穩後再推全量。監控報警：全方位的監控體系，包括最基礎的cpu、記憶體、磁碟、網路的監控，web伺服器、資料庫、各類中介軟體的監控和業務指標的監控。
高擴充套件的方案：合理的分層架構，儲存層的拆分，業務層的拆分。
高併發設計秉承架構設計的3個原則：簡單、合適和演進。「過早的優化是萬惡之源」，不能脫離業務的實際情況，更不要過度設計，合適的方案就是最完美的。
高併發高可用（一）概念和技術架構雜談
乙個系統的吞度量 承壓能力 系統在單位時間內處理請求的數量，體現系統整體處理能力 與request對cpu的消耗 外部介面 io等等緊密關聯。單個request對cpu消耗越高，外部系統介面 io影響速度越慢，系統吞吐能力越低，反之越高。吞度量常用量化指標有每秒事務數tps 每秒查詢率qps 每秒h...
高併發 高可用
高併發 提高系統併發能力的方法主要有兩種 前者垂直擴充套件可以通過提公升單機硬體效能，或者提公升單機架構效能，來提高併發性，但單機效能總是有極限的，網際網路分布式架構設計高併發終極解決方案還是後者 水平擴充套件。網際網路分層架構中，各層次水平擴充套件的實踐又有所不同 1 反向 層可以通過 dns輪詢...
高併發 高併發測試筆記
問 高併發測試 一般你們用什麼工具來模擬 10萬級別的客戶端併發？在普通的電腦上可以模擬嗎 10萬併發需要至少10萬的套接字，套接字在核心中占用記憶體100000 6k 2 1g記憶體，系統需要能夠開啟10w個fd。一般的系統能夠能模擬 問 預設每個程序只能開1024個fd，修改後最大可以10w，那...