高并發

在當今互聯網時代，無論是電商平臺的促銷活動，還是社交媒體的熱點事件，都可能瞬間涌入大量的用戶請求。

圖片

高并發帶來的挑戰是巨大的：服務器資源緊張、響應速度變慢、甚至系統崩潰。

TPS突破5萬對于許多大規模在線業務而言，是一個關鍵的技術目標。

TPS（Transactions Per Second）：是衡量系統每秒處理事務數量的標準指標。

圖片

TPS反映了系統的吞吐能力，它直接關系到系統的性能、響應時間和用戶體驗。

具體來說，5萬TPS代表著系統每秒可以處理50,000個事務，這對于大多數電商平臺、金融交易系統、社交應用等場景來說是一個巨大的挑戰。

突破這一目標意味著架構能夠處理更加復雜的業務請求，同時也能夠應對突發的流量高峰。

我們需要深入分析，究竟是什么樣的架構，才能夠支撐如此高的并發。

如何支撐高并發？

當TPS達到5萬時，系統將面臨諸多挑戰。

首先，數據庫的訪問成為瓶頸。

因為在高并發的情況下，大量的數據庫查詢、和寫入操作可能導致數據庫的負載過高，響應時間延遲。

這個時候，可以考慮“分庫分表”，將數據分散存儲，避免單一數據庫的壓力過大。

圖片

通過分庫分表，可以將不同的數據存儲到不同的數據庫中，使得不同數據表的讀寫操作能夠并行執行，提高并發性能。

阿里巴巴的電商平臺，例如淘寶、天貓，面對的是海量用戶、商品和訂單，單一數據庫顯然無法支撐。

因此，分庫拆分是其架構設計的必然選擇。

業務領域劃分

將核心業務領域獨立拆分，形成獨立的數據庫，實現業務隔離和數據解耦。

確保每個數據庫承擔明確的業務職責。

常見的分庫包括：

圖片

用戶庫：存儲用戶信息、賬戶信息...等。

商品庫：存儲商品信息、庫存信息...等。

訂單庫：存儲訂單信息、支付信息...等。

交易庫：存儲交易信息，支付信息...等。

店鋪庫：存儲店鋪信息...等。

還可以，按用戶ID范圍、或哈希取模，進一步拆分成多個表。

比如user_table_01、user_table_02....，分散壓力。

讀寫分離

通過主從數據庫復制，讀操作由從數據庫處理，寫操作由主數據庫處理，減輕主數據庫的負擔。

讀寫分離的核心是主從復制，主數據庫（主庫）負責處理所有的寫操作（INSERT、UPDATE、DELETE），而從數據庫（從庫）則復制主庫的數據，并處理讀操作（SELECT）。

主庫將寫操作的日志（例如，MySQL的binlog）同步到從庫，從庫通過執行這些日志來保持與主庫數據的一致性。

高性能緩存

分布式緩存系統是高并發架構中的關鍵組成部分，通過使用如Redis、Memcached...等，緩存系統。

緩存系統通常用于存儲：熱點數據、查詢結果等高頻訪問的數據，可以大大減少數據庫的訪問頻率，提升響應速度。

但也需要考慮，在高并發流量的情況下，穿透、雪崩...等等場景。

圖片

緩存穿透

緩存穿透是指查詢一個不存在的數據，緩存和數據庫中都沒有這條數據，導致每次請求都會直接訪問數據庫。

如果大量請求查詢不存在的數據，數據庫會承受巨大的壓力，甚至崩潰。

解決方案

使用布隆過濾器來判斷請求的數據是否存在。

布隆過濾器是一種高效的數據結構，可以快速判斷一個元素是否存在于集合中。

如果布隆過濾器判斷數據不存在，則直接返回，避免訪問緩存和數據庫。

緩存雪崩

緩存雪崩是指大量緩存數據在同一時間失效，導致大量請求直接訪問數據庫，造成數據庫壓力過大，甚至崩潰。

解決方案：

設置隨機過期時間，來解決。

為緩存數據設置隨機的過期時間，避免大量緩存數據同時失效。

緩存預熱

在系統啟動時，提前加載熱點數據到緩存中，避免大量請求直接訪問數據庫。

使用多級緩存，例如，本地緩存和分布式緩存結合使用。

構建高可用緩存集群

對于redis等緩存服務，做集群，或者使用哨兵模式，避免單點故障，提高可用性。

流量削峰

通過消息隊列（如Kafka、RocketMQ...等），可以將高峰流量中的請求異步地推送到隊列中，消費者按照設定的速率從隊列中取出消息進行處理。

這樣，系統可以在流量較低時處理請求，避免了系統因瞬時高并發而崩潰。

例如，在電商平臺中，用戶下單后，可以將支付請求通過消息隊列推送到處理隊列，由后臺異步處理支付請求，避免高并發時同步處理的壓力。

以及，在秒殺活動中，用戶的請求量可能會激增，消息隊列可以幫助將大量請求排入隊列中，逐步處理，以避免系統崩潰。