高併發架構設計經驗總結

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

高併發架構設計經驗

一、高併發的說明和背景

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

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

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

二、高併發架構設計經驗

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

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

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