?文章目錄
目錄
?文章目錄
前言
一、通用設計
一、動靜分離
二、數據庫獨立部署
三、問題
1.高并發通用設計方法
2.高并發系統的拆分順序
二、計算資源高并發
三、網絡資源高并發
超高性能場景（10萬+ QPS）
中小規模場景（5萬 QPS以下）
四、數據庫高并發
五、
前言
高并發設計可以分為5個部分1.通用設計
1.
面對100萬級別的QPS該怎么設計？
請看以下步驟
一、通用設計
一、動靜分離
動靜分離是高并發的第一步
最開始的項目我們都是要apache tomcat 來承載動態（java http請求）和靜態文件（將html、css等放入static文件），而使用動靜分離是指的將靜態文件（前端預先加載到頁面上的內容）放入nginx中
為什么用nginx，nginx處理性能大概是tomcat的4倍
使用云服務?
CDN（Content Delivery Network，內容分發網絡）?是優化靜態資源訪問速度和降低服務器負載的核心手段
將全部資源交給云服務廠商的CDN來承載，還以獲得90%的CPU節省
對比
| 場景 | CDN 直接承載 | Nginx + CDN |
|---|---|---|
| 架構復雜度 | 無需服務器，純云服務 | 需維護 Nginx 服務器 |
| 成本 | 按需付費（存儲+流量） | 服務器固定成本 + CDN 流量成本 |
| 擴展性 | 自動彈性擴展 | 需手動擴容服務器 |
| 適用場景 | 純靜態資源 | 需動態生成內容（如縮略圖） |
二、數據庫獨立部署
如果使用nginx來承載靜態資源之后，云主機還是扛不住流量，那么這時候就應該再用一臺主機來：專門跑數據庫，甚至有些數據庫是部署到多臺服務器上
一般來說我們不會將項目（后端代碼）和數據庫部署到同一臺服務器上，這種是典型的災難架構
這里建議直接使用云服務商的云數據庫，因為一旦你的qps超過1000，自建數據庫就很難滿足要求了，如果搭建集群，小公司成本又太高，而直接使用云數據庫就不會出現這種問題，他會自動調整資源
三、問題
1.高并發通用設計方法
高并發系統遇見瓶頸，一定是某個資源點到達極限，例如數據庫，服務器，帶寬等，因此需要找到這個受限點，拆分并解決
1.負載均衡：分散請求到多個服務器，減少單臺服務器壓力，例如nginx
2.緩存技術：將經常訪問的數據放入緩存（內存中），減少數據庫壓力，并提高系統響應速度，例如redis
3.異步處理：多線程方式，讓任務在后臺處理，而主線程先返回。提高系統響應速度，釋放服務器占用線程
4.消息隊列：將龐大的任務，放入消息隊列，由另一個線程或者多個線程來處理，實現異步，削峰，解耦等作用
5.數據庫優化：優化SQL,設置數據庫集群都可以提高數據庫響應速度，從而提高系統響應
6.水平擴展：拆解系統，分別部署到不同服務器，來減少單臺服務器cpu壓力
7.服務隔離：高并發系統中，不同的模塊或者說平臺，一般都有隔離開，保證不同服務之間互不影響
2.高并發系統的拆分順序
高并發系統的拆分應該從靜態資源開始拆分，然后在到數據庫和服務器機器分離，然后再設計負載均衡和分布式架構，最后再利用數據庫集群和分布式數據庫來提升數據庫能力，期次再考慮其他優化手段
1.靜態資源拆分：將原本后端項目集成的靜態資源，拆分到nginx或者cdn中進行存儲
2.數據庫和后端服務機器分離：將數據庫和后端服務放到不同的機器上，這樣能減少數據庫壓力，并提高擴展能力
3.負載均衡和分布式架構：通過負載均衡將同一個項目部署到多臺機器（也就是多個實例，換句話來說就是用戶的請求分發到不同的機器上），提高系統處理能力，同時，采用分布式架構（將系統拆分成獨立模塊，再），利用多個機器同時進行服務，進一步提高系統并行能力
4.數據庫集群和分布式數據庫：數據庫集群是將多個數據庫實例分布到不同的服務器上，通過數據同步和故障轉移機制，保證數據庫的高可用，分布式數據庫是將數據分散到多個節點上，每個數據只負責部分數據的存儲和查詢，從而提高整個系統的讀寫能力
5.基于地域進行數據庫拆分：
3.靜態資源如何加速：
1.高性能web服務器
2.CDN服務：將靜態資源分散到全國，用戶就能從最近的服務器獲取消息，減少延遲
二、計算資源高并發
目標：拆分計算單點，提升并行能力。
主要是部署方法的轉變?物理機 → 虛擬機 → 容器化，解決計算資源利用率與彈性問題。
| 階段 | 核心方案 | 解決的問題 | 瓶頸 |
|---|---|---|---|
| 單服務部署 | 單機運行所有服務 | 簡單部署 | 資源爭搶（CPU/內存耗盡） |
| 虛擬機部署 | VMware/KVM 虛擬化 | 資源隔離，多應用共存 | 虛擬機啟動慢（分鐘級） |
| 容器化 | Docker + Kubernetes | 進程級隔離，秒級啟動 | 內核兼容性 |
三、網絡資源高并發
這里大致總結：就是在7層網絡模型上進行高并發的設計
首先gateway或者nginx單臺支持的最大qps有限，通常32核的支持萬級qps，那么怎么承擔上百萬QPS呢，這時候就需要在傳輸層搭建服務LVS,這里能支持百萬級別QPS
| 層級 | OSI模型 | 代表組件 | 核心職責 |
|---|---|---|---|
| 數據鏈路層 | L2 (鏈路層) | F5 (部分功能) | MAC地址轉發、VLAN隔離 |
| 網絡層 | L3 (網絡層) | LVS、F5 (IP轉發) | IP包路由、四層負載均衡(TCP) |
| 傳輸層 | L4 (傳輸層) | LVS、HAProxy | TCP/UDP連接分發 |
| 應用層 | L7 (應用層) | Nginx/Kong/Gateway | HTTP協議解析、動態路由 |
通過分層架構：
-
L4 負載層：用低成本解決海量連接分發（LVS/硬件）
-
L7 網關層：專注業務協議處理（Kong/Nginx）
-
業務層：無網絡負擔，專注計算
超高性能場景（10萬+ QPS）
-
優勢：
-
Nginx專做TLS解密（C語言極致性能）
-
Gateway專注業務路由（無需處理加密）
-
整體吞吐量提升2倍+
-
實例：加入現在目標6萬QPS
中小規模場景（5萬 QPS以下）
下面是百萬QPS的真實案例
| 層級 | 組件 | 配置 | 數量 | 總處理能力 |
|---|---|---|---|---|
| 網絡入口 | LVS + DPDK | 64核/128G/100G網卡 | 4臺 | 400萬 CPS |
| TLS卸載 | Nginx + 加速卡 | 32核/64G/SSL卡 | 20臺 | 120萬 TPS |
| 業務網關 | Rust網關(io_uring) | 32核/64G | 30臺 | 450萬 QPS |
| 微服務 | 商品服務 | 16核/32G | 50臺 | 200萬 QPS |
四、數據庫高并發
核心挑戰：數據庫是“最難以解決的單點”，因其需保證 ACID 事務。
-
存儲技術演進：
-
集中式存儲（如 EMC）：硬件級高可用，但成本極高（單 SAN 交換機超 40 萬元）。
-
分布式存儲：通過 x86 服務器集群構建存儲池，依賴 PCIe 5.0 和 CXL 協議提升 IO 性能，降低成本。
-
-
數據庫架構優化：
-
緩存策略：Redis 緩存熱點數據，OceanBase 等分布式數據庫采用“內存全緩存 + Redo Log 落盤”方案。
-
分布式方案：
-
TiDB（計算存儲分離）、ClickHouse（列存儲）解決海量數據分析瓶頸。
-
分庫分表 + Paxos 協議保障數據一致性與高可用。
-
-
為了提高數據庫讀寫能力，搭建讀寫分離1主多從，提高讀能力，那么寫能力呢，寫是往主節點寫入的，這時候就需要分布式架構了
第一代分布式架構 使用中間件 sharding-jdbc，但是可以說是屬于應用層面不，不屬于通用數據庫范疇
第二代，出現了kv型數據庫，nosql(redis）KV 數據庫結構簡單，性能優異，擴展性無敵，但是它只能作為核心數據庫的高性能補充
第三個時代，newSQL,目前比較常見的 NewSQL 有 ClustrixDB、NuoDB、VoltDB，國內的 TiDB 和 OceanBase 也屬于 NewSQL
第四個時代，云上數據庫 例如阿里的PolarDB?
緩存和隊列
緩存（redis）消讀的峰，而隊列（rockemq,kafka）消寫的峰
五、
持續更新。。。
