高并發架構設計經驗總結

高并發解決的核心問題是在同一時間上有大量的請求過來，然后我們的系統要怎么抗住這些請求帶來的壓力，本文從基礎設施層、服務端架構層、服務應用層分別做了一個簡單的梳理，在每一層通過什么的方式去抗并發，給大家提供一個思路，

高并發架構設計經驗

一、高并發的說明和背景

高并發解決的核心問題是在同一時間上有大量的請求過來，然后我們的系統要怎么抗住這些請求帶來的壓力，比如在線直播服務，同時有上百萬甚至上千萬人觀看，比如秒殺品，同時有大量用戶涌入，

高并發是從業務角度去描述系統的能力，實作高并發的手段可以采用分布式，也可以采用快取等，當然也包括多執行緒、協程，但遠遠不僅如此；高并發的基本表現為單位時間內系統能夠同時處理的請求數，高并發的核心是對資源的有效壓榨，有限的資源應對大量的請求，

現代互聯網服務，基本上都要考慮高并發問題，因為一般的產品，用戶的請求量都很大，

二、高并發架構設計經驗

高并發架構設計，需要從三大層來建設和分析

• 基礎設施層：這個是最基礎的依賴，主要是一些服務的部署，針對大公司而言，一般都有成熟的系統和基礎設施來承載，可能針對業務開發的同學來看，平時關注的的細節并不深入，但是不妨礙我們從全域角度來剖析高并發的設計，
• 服務端架構層：這個是我們重點要關注的架構設計，架構設計不合理，就很難抗住高并發，主要包括各種架構和模塊的設計，
• 服務應用層： 這個主要是針對我們寫的代碼來進行優化改進，從代碼架構、代碼性能等方便去抗并發，

2-1、基礎設施層

部署：多 IDC + 異地多活

基礎設施層一般包含了服務器、IDC、部署方式等等，目前而言，我們一般都用容器部署的方式，而容器的底層能力基本也都是建立在 k8s 容器層之上的，服務本身的部署管理已經有成熟的設施幫我們實作了，具體到部署方式，包括但不限于：

• 多 IDC 部署，比如服務同時在廣州、上海兩地部署， 這個依賴我們的服務是無狀態的
• 其他的參考下 異地多活架構等相關部署，

監控：可觀測性

系統的可觀測性主要包含三個部分: logging、tracing、metrics， 這個一般都要引入可觀測系統，這樣才能幫助我們在例外的時候能夠快速定位問題，屬于必備設施，一般而言，公司應該都有專門的團隊去做這個事情，

2-2、服務端架構層

服務端架構層是我們重點要關注的，這個也是考量個人架構能力的最關鍵部分，

系統分層設計：分層、分割、分布式

• 架構分層
• 將系統在橫向維度上切分成幾個部分，每一層的功能職責要足夠單一，然后通過上層對下層的依賴和調度組成一個完整的系統
• 比如把電商系統分成：應用層，服務層，資料層，(具體分多少個層次根據自己的業務場景)
• 應用層：網站首頁，用戶中心，商品中心，購物車，紅包業務，活動中心等，負責具體業務和視圖展示
• 服務層：訂單服務，用戶管理服務，紅包服務，商品服務等，為應用層提供服務支持
• 資料層：關系資料庫，nosql 資料庫 等，提供資料存盤查詢服務
• 業務分割
• 在縱向方面對業務進行切分，將一塊相對復雜的業務分割成不同的模塊單元，對應的是模塊的劃分，通過合理的模塊劃分，使得每個模塊都能可以滿足 高內聚低耦合 的設計要求，這樣不同的模塊可以分布式部署，也能提高并發處理能力和功能擴展
• 比如用戶中心可以分割成：賬戶資訊模塊，訂單串列模塊，充值模塊，優惠券模塊等
• 分布式
• 分布式應用和服務,將分層或者分割后的業務分布式部署，獨立的應用服務器，資料庫，快取服務器，當業務達到一定用戶量的時候，再進行服務器均衡負載，資料庫，快取主從集群

集群架構設計：應用集群、資料集群

應對高并發系統，不管是應用層面還是資料層面，單機都不可能搞定，因此都需要搭建集群架構，然后通過負載均衡來對外提供服務，同時集群架構還能保證系統的可用性，當某臺服務或者機器例外，負載均衡會自動剔除，不會影響對外服務，

• 應用服務器集群
• nginx 反向代理
• slb
• LVS …
資料集群(關系/nosql 資料庫)
• 主從分離，一主多從
• 資料讀寫分離

資料庫設計：讀寫分離+分庫分表+冷熱分離

應對高并發，資料的存盤，首先就要做好預估，先進行分庫分表 和 讀寫分離，最后可以根據情況來看是否冷熱分離：

• 讀寫分離，互聯網系統大多數都是讀多寫少，因此讀寫分離可以幫助主庫抗量，一般我們都是一主多從的架構，可以抗量，也可以保證資料不丟，分庫分表只能解決 QPS 高，但是無法解決 TPS 高，比如寫入的量足夠大的話（TPS 高），就得讀寫分離，
• 分庫分表，資料存盤量大的時候，就需要通過分庫分表來存盤，先分，避免后期要拆，后期拆的話，就面臨洗資料的問題，就需要采用雙寫模式來搞定，
• 分庫分表模式雖然能顯著提升資料庫的容量，但會增加系統復雜性，而且由于只能支持少數的幾個維度讀寫，從某種意義上來說對業務系統也是一種限制，因此在設計分庫分表方案的時候需要結合具體業務場景，更全面的考慮，

• 冷熱分離，針對業務場景而言，如果資料有冷熱之分的話，可以將歷史冷資料與當前熱資料分開存盤，這樣可以減輕當前熱資料的存盤量，可以提高性能，

不過，既然是高并發系統，不能應用層直接讀寫 DB 的，一定有一個快取在上面，如果直接讀寫 DB 能夠搞定，其實不能叫高并發了，只能說是并發有點高，在非互聯網系統里面還是可以的，

快取設計：多級快取架構和本地快取

快取的最大作用是可以提升系統性能，保護后端存盤不被大流量打垮，增加系統的伸縮性，快取的設計，需要分多個思路并行

• 首先要考慮的，就是必須在資料庫之上，增加一層分布式快取，比如 Redis 或者 Memcached，
• 這里需要考慮一下快取和資料庫一致性的問題，
• 其次需要考慮的是多級快取架構，分幾級快取設計，同時設計熱點快取架構，
• 在分布式快取之上，還可以加一個本地快取，來快取最熱的資料
• 采用多個分布式快取來搭建多級快取，

訊息佇列設計：MQ 抗量和削峰

針對流量突峰，僅僅有快取來抗量可能還不夠，還需要使用訊息佇列來削峰，使用訊息佇列后，可以將同步處理的請求改為 通過消費 MQ 訊息來異步消費，這樣可以大大減少系統處理的壓力，增加系統的并發量，常用的訊息佇列比如 kafka，

服務治理設計：超時、熔斷、降級、限流等

超時、熔斷、降級、限流等都是常規策略，可以在另外服務治理章節去細看，

資源隔離設計： SET 部署

資源隔離有各種型別，物理層面的服務器資源、中間件資源，代碼層面的執行緒池、連接池，這些都可以做隔離，

一般我們最常見的就是應用部署層面的，比如 SET 化部署，一個服務對外的使用方可能有 A 業務、B 業務，那么如何保證 AB 業務不會相互影響，那么就是 SET 化部署， SET 化部署也可以防止非關鍵業務來影響關鍵核心業務，一個隔離的維度可以是按業務場景區分，分為關鍵集群、次關鍵集群和非關鍵集群三類，這樣能避免關鍵和非關鍵業務互相影響，

SET 化部署就是把業務系統分為多個可擴展的邏輯磁區，每個 SET 化的邏輯磁區都可以獨立部署并提供服務，SET 也可以理解為 ”邏輯機房“ ，主要目的就是為了進行獨立部署并且做到業務上的邏輯隔離，

關于 SET 的具體例子：微信紅包用戶發一個紅包時，微信紅包系統生成一個 ID 作為這個紅包的唯一標識，接下來這個紅包的所有發紅包、搶紅包、拆紅包、查詢紅包詳情等操作，都根據這個 ID 關聯，紅包系統根據這個紅包 ID，按一定的規則（如按 ID 尾號取模等），垂直上下切分，切分后，一個垂直鏈條上的邏輯 Server 服務器、DB 統稱為一個 SET，各個 SET 之間相互獨立，互相解耦，并且同一個紅包 ID 的所有請求，包括發紅包、搶紅包、拆紅包、查詳情詳情等，垂直 stick 到同一個 SET 內處理，高度內聚，通過這樣的方式，系統將所有紅包請求這個巨大的洪流分散為多股小流，互不影響，分而治之，

2-3、服務應用層

多執行緒、執行緒同步、協程

并發問題一直是服務端編程中的重點和難點問題，為了優化系統的并發量，單機解決高并發問題從最初的 Fork 行程開始，到行程池/執行緒池，再到 Epoll 事件驅動(Nginx)，再到協程（如 Goroutine），

對于 Go 語言，盡可能的多使用協程去提高并發能力，

異步化

訊息佇列也是一種異步化操作，但是除了依賴外部的中間件如訊息佇列，在應用內我們也可以通過執行緒池、協程的方式做異步化，能異步的盡量異步處理，這樣可以提高并發，

預處理：預加載、預熱

系統的預熱一般有 JVM 預熱、快取預熱、DB 預熱等，通過預熱的方式讓系統先“熱”起來，為高并發流量的到來做好準備， 預熱實際應用的場景有很多，比如在電商的大促到來前，我們可以把一些熱點的商品提前加載到快取中，防止大流量沖擊 DB，

還有一種預熱的思路是利用業務的特性做一些預加載，比如 feeds 流重繪的時候，提前加載 1-2 頁資料，這樣用戶往下重繪的時候，就感覺不到卡頓，

作者：allendbwu

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Summary-of-High-Concurrency-Architecture-Design-Experience.html

標籤：其他

上一篇：PowerDotNet平臺化軟體架構設計與實作系列（15）：支付平臺

下一篇：23種設計模式，你學廢了嘛？