高併發解決方案詳解(9大常見解決方案)

來源：mikechen的網際網路架構

高併發是非常重要的架構核心技能，比如：阿里的雙11秒殺就是典型的高併發場景，短時間來搶購，技術如何解決，這就會涉及到高併發的解決方案，下面我給大家詳解9大高併發解決方案

微服務拆分

分散式架構會從一個拆分為多個系統，每個系統都有獨立的資料庫等，透過這樣的橫向擴充套件，就可以支撐更大的併發量。

微服務架構拆分，最常見的就是Spring Cloud 和Spring Cloud Alibaba。

Spring Cloud，會體系包含如下：

這裡就會涉及到：服務發現、負載均衡、配置管理、熔斷、路由等，Spring Cloud 提供了一系列元件和模組來解決這些問題。

除此之外，還會涉及到阿里巴巴打造的Spring Cloud Alibaba。

如下圖所示：

Spring Cloud Alibaba 提供了一些核心元件和功能：

1. Nacos： Nacos（Naming and Configuration Service）是一個服務註冊與發現、配置管理的平臺，可以用於動態註冊和發現服務、管理配置資訊等。

2. Sentinel： Sentinel 是一個開源的流量控制和熔斷框架，用於保護分散式系統免受不穩定的外部資源的影響。

3. RocketMQ： RocketMQ 是一個分散式訊息佇列，用於實現非同步訊息通訊。

4. Dubbo： Dubbo 是一個高效能的分散式服務框架，用於實現微服務架構中的服務呼叫和遠端通訊。

5. Seata： Seata 是一個開源的分散式事務解決方案，用於管理分散式事務的一致性和隔離性。

更加詳細的請檢視：Spring Cloud Alibaba詳解(史上最全元件文件教程)

負載均衡

負載均衡（Load Balancing）是一種分散式系統架構中的技術，用於將網路請求或任務分散到多個伺服器或資源上。

比如：當系統面臨大量使用者訪問，負載過高的時候，通常會使用增加伺服器數量來進行橫向擴充套件來提高整個系統的處理能力。

如下圖所示：

上圖的：tomcat-node1、tomcat-node2、tomcat-node3這些節點就可以橫向擴充套件，透過多臺伺服器來承擔併發壓力。

負載均衡可以在不同的層次上實現，包括：

• 硬體負載均衡器： 使用專門的硬體裝置來實現負載均衡，如硬體負載均衡器。

• 軟體負載均衡器： 在應用層或網路層使用軟體來實現負載均衡，如反向代理伺服器、負載均衡演算法。

在負載均衡的設計中，有幾種常見的負載均衡策略：

1. 輪詢（Round Robin）： 將請求依次分配給伺服器列表中的每個伺服器，每次請求後移動到下一個伺服器。適用於伺服器效能相近的情況。

2. 權重輪詢（Weighted Round Robin）： 類似於輪詢，但每個伺服器有不同的權重，可以根據伺服器效能調整權重。

3. 最少連線（Least Connections）： 將請求分配給當前連線數最少的伺服器，以確保負載均衡。適用於長連線的情況。

4. 權重最少連線（Weighted Least Connections）： 類似於最少連線，但每個伺服器有不同的權重，可以根據伺服器效能調整權重。

5. 隨機（Random）： 隨機選擇一個伺服器來處理請求，適用於簡單的負載均衡需求。

6. IP 雜湊（IP Hash）： 根據客戶端 IP 地址的雜湊值來選擇伺服器，可以確保同一客戶端的請求始終傳送到同一伺服器。

更加詳細的請檢視：最全負載均衡圖文詳解(9大負載原理演算法)

分散式快取

大部分的高併發場景，都是讀多寫少，要想提高資料的訪問速度，那系統必須得加快取。

原因很簡單，快取的讀寫效率，遠遠大於資料庫的讀寫效率。

所以，這裡我們都會採用分散式快取來提升效能。

一些常見的分散式快取系統包括：

• Redis： Redis 是一種基於記憶體的鍵值儲存系統，支援多種資料結構，如字串、雜湊、列表等，適用於快速讀取和寫入場景。

• Memcached： Memcached 也是一種基於記憶體的鍵值儲存系統，適用於分散式快取和快取共享。

• Hazelcast： Hazelcast 是一個開源的分散式資料儲存和計算平臺，支援分散式快取、分散式計算等。

• Couchbase： Couchbase 是一個分散式快取和資料庫系統，結合了快取和文件儲存的功能。

• Ehcache： Ehcache 是一個 Java 快取庫，可以作為本地快取或分散式快取使用。

當然，這裡使用最多的還是Redis。

非同步處理

對於一些耗時的操作，比如：下訂單後的發簡訊，併發量大的情況下同步操作極為耗時，需要改造為非同步請求。

如下圖所示：

非同步發簡訊的核心思想是將簡訊傳送操作放入非同步任務中，讓主程式繼續執行，不必等待簡訊傳送完成。

與同步處理相比，非同步處理不會阻塞主執行緒的執行，允許主執行緒繼續執行其他任務，而非同步任務在後臺或其他執行緒中完成。

非同步處理可以實現多個任務的並行執行，提高系統的併發處理能力。

分庫分表

類似淘寶這樣的網站，海量資料的儲存和訪問成為了系統設計的瓶頸問題，一張表超過了億級資料，都會考慮拆分。

日益增長的業務資料，無疑對資料庫造成了相當大的負載，這裡就會涉及到垂直拆分和水平拆分等。

分庫分表的核心思想，主要包含：分庫和分表

如下圖所示：

1.分庫（Sharding）

將不同的資料儲存到不同的資料庫例項中。例如，可以根據資料的某個特徵（如使用者ID、地理位置等）將資料分散到不同的資料庫。

2.分表（Sharding）

將單個表拆分成多個子表。例如，可以將一個使用者表拆分成多個子表，每個子表儲存一部分使用者資料。

這裡需要涉及到：分庫分表中介軟體，比如：ShardingJDBC、ShardingSphere等，可以幫助實現分庫分表的功能。

用的分庫分表中介軟體，如下圖所示：

更加詳細的請檢視：分庫分表最全詳解(史上最強圖文版)

訊息佇列

訊息佇列（Message Queue）是一種在分散式系統中用於非同步通訊的架構模式，它可以實現解耦、非同步處理、削峰填谷等目標。

特比是在高併發的雙11秒殺場景，都會用到訊息佇列來解決削峰填谷等問題。

當系統面臨突發的大量請求時，可以將請求暫時儲存在訊息佇列中，然後按照系統的處理能力逐步消費和處理。

這種方式可以避免系統被過載和崩潰，適用於流量波動較大的場景，特別適用於高併發的場景。

一些常見的訊息佇列系統包括：RabbitMQ、Kafka、RocketMQ等。

限流和熔斷

限流（Rate Limiting）和熔斷（Circuit Breaking）是分散式系統中常用的兩種流量控制和容錯機制。

用於保護系統免受異常情況下的影響，提高系統的穩定性和可用性。

如下圖所示:

如果各個服務正常執行，那大家齊樂融融，但是如果其中一個服務Service C崩壞掉會出現什麼樣的情況呢？

很有可能就會出現，下圖的拖掛別的服務場景。

特別是併發量高的情況下，首先需要保護核心系統的安全性，所以常常會涉及到限流和熔斷。

分散式資料庫

分散式資料庫是一種資料庫系統，將資料分散儲存在多個物理節點或伺服器上，以提高系統的效能、可擴充套件性和可用性。

這裡會涉及到：

1.分散式關係型資料庫

這類資料庫將關係型資料庫的特性與分散式系統的優勢相結合，提供了支援SQL查詢和事務的能力。

一些例子包括：Google Cloud Spanner、TiDB一種全球分散式的關係型資料庫，提供了強一致性和水平擴充套件能力。

2.分散式列式資料庫

這類資料庫以列式儲存方式儲存資料，適用於大規模分析和查詢需求。

Apache Cassandra：一個分散式的NoSQL資料庫，適用於高可用性和可擴充套件性的場景。

HBase：一個基於Hadoop的分散式列式資料庫，適用於大資料儲存和實時查詢。

3.分散式文件資料庫

這類資料庫以文件為單位儲存資料，適用於半結構化資料。

MongoDB：一個面向文件的NoSQL資料庫，支援分散式部署和水平擴充套件。

Couchbase：一個分散式NoSQL資料庫，支援文件和鍵值資料模型。

使用分散式資料庫系統，如分散式 NoSQL 資料庫，來提高資料儲存和查詢的併發處理能力。

資料庫最佳化

最佳化資料庫的設計、索引、查詢語句等，提高資料庫的讀寫效能。

綜合運用上述高併發架構解決方案，都可以構建出具有高效能、高可用和可擴充套件性的系統，滿足大量併發請求的需求。

以上