高并發(fā)場景下,TPS如何突破5萬并發(fā)?
高并發(fā)
在當今互聯(lián)網(wǎng)時代,無論是電商平臺的促銷活動,還是社交媒體的熱點事件,都可能瞬間涌入大量的用戶請求。
圖片
高并發(fā)帶來的挑戰(zhàn)是巨大的:服務器資源緊張、響應速度變慢、甚至系統(tǒng)崩潰。
TPS突破5萬對于許多大規(guī)模在線業(yè)務而言,是一個關(guān)鍵的技術(shù)目標。
TPS(Transactions Per Second):是衡量系統(tǒng)每秒處理事務數(shù)量的標準指標。
圖片
TPS反映了系統(tǒng)的吞吐能力,它直接關(guān)系到系統(tǒng)的性能、響應時間和用戶體驗。
具體來說,5萬TPS代表著系統(tǒng)每秒可以處理50,000個事務,這對于大多數(shù)電商平臺、金融交易系統(tǒng)、社交應用等場景來說是一個巨大的挑戰(zhàn)。
突破這一目標意味著架構(gòu)能夠處理更加復雜的業(yè)務請求,同時也能夠應對突發(fā)的流量高峰。
我們需要深入分析,究竟是什么樣的架構(gòu),才能夠支撐如此高的并發(fā)。
如何支撐高并發(fā)?
當TPS達到5萬時,系統(tǒng)將面臨諸多挑戰(zhàn)。
首先,數(shù)據(jù)庫的訪問成為瓶頸。
因為在高并發(fā)的情況下,大量的數(shù)據(jù)庫查詢、和寫入操作可能導致數(shù)據(jù)庫的負載過高,響應時間延遲。
這個時候,可以考慮“分庫分表”,將數(shù)據(jù)分散存儲,避免單一數(shù)據(jù)庫的壓力過大。
圖片
通過分庫分表,可以將不同的數(shù)據(jù)存儲到不同的數(shù)據(jù)庫中,使得不同數(shù)據(jù)表的讀寫操作能夠并行執(zhí)行,提高并發(fā)性能。
阿里巴巴的電商平臺,例如淘寶、天貓,面對的是海量用戶、商品和訂單,單一數(shù)據(jù)庫顯然無法支撐。
因此,分庫拆分是其架構(gòu)設計的必然選擇。
業(yè)務領(lǐng)域劃分
將核心業(yè)務領(lǐng)域獨立拆分,形成獨立的數(shù)據(jù)庫,實現(xiàn)業(yè)務隔離和數(shù)據(jù)解耦。
確保每個數(shù)據(jù)庫承擔明確的業(yè)務職責。
常見的分庫包括:
圖片
用戶庫:存儲用戶信息、賬戶信息...等。
商品庫:存儲商品信息、庫存信息...等。
訂單庫:存儲訂單信息、支付信息...等。
交易庫:存儲交易信息,支付信息...等。
店鋪庫:存儲店鋪信息...等。
還可以,按用戶ID范圍、或哈希取模,進一步拆分成多個表。
比如user_table_01、user_table_02....,分散壓力。
讀寫分離
通過主從數(shù)據(jù)庫復制,讀操作由從數(shù)據(jù)庫處理,寫操作由主數(shù)據(jù)庫處理,減輕主數(shù)據(jù)庫的負擔。
讀寫分離的核心是主從復制,主數(shù)據(jù)庫(主庫)負責處理所有的寫操作(INSERT、UPDATE、DELETE),而從數(shù)據(jù)庫(從庫)則復制主庫的數(shù)據(jù),并處理讀操作(SELECT)。
主庫將寫操作的日志(例如,MySQL的binlog)同步到從庫,從庫通過執(zhí)行這些日志來保持與主庫數(shù)據(jù)的一致性。
高性能緩存
分布式緩存系統(tǒng)是高并發(fā)架構(gòu)中的關(guān)鍵組成部分,通過使用如Redis、Memcached...等,緩存系統(tǒng)。
緩存系統(tǒng)通常用于存儲:熱點數(shù)據(jù)、查詢結(jié)果等高頻訪問的數(shù)據(jù),可以大大減少數(shù)據(jù)庫的訪問頻率,提升響應速度。
但也需要考慮,在高并發(fā)流量的情況下,穿透、雪崩...等等場景。
圖片
緩存穿透
緩存穿透是指查詢一個不存在的數(shù)據(jù),緩存和數(shù)據(jù)庫中都沒有這條數(shù)據(jù),導致每次請求都會直接訪問數(shù)據(jù)庫。
如果大量請求查詢不存在的數(shù)據(jù),數(shù)據(jù)庫會承受巨大的壓力,甚至崩潰。
解決方案
使用布隆過濾器來判斷請求的數(shù)據(jù)是否存在。
布隆過濾器是一種高效的數(shù)據(jù)結(jié)構(gòu),可以快速判斷一個元素是否存在于集合中。
如果布隆過濾器判斷數(shù)據(jù)不存在,則直接返回,避免訪問緩存和數(shù)據(jù)庫。
緩存雪崩
緩存雪崩是指大量緩存數(shù)據(jù)在同一時間失效,導致大量請求直接訪問數(shù)據(jù)庫,造成數(shù)據(jù)庫壓力過大,甚至崩潰。
解決方案:
設置隨機過期時間,來解決。
為緩存數(shù)據(jù)設置隨機的過期時間,避免大量緩存數(shù)據(jù)同時失效。
緩存預熱
在系統(tǒng)啟動時,提前加載熱點數(shù)據(jù)到緩存中,避免大量請求直接訪問數(shù)據(jù)庫。
使用多級緩存,例如,本地緩存和分布式緩存結(jié)合使用。
構(gòu)建高可用緩存集群
對于redis等緩存服務,做集群,或者使用哨兵模式,避免單點故障,提高可用性。
流量削峰
通過消息隊列(如Kafka、RocketMQ...等),可以將高峰流量中的請求異步地推送到隊列中,消費者按照設定的速率從隊列中取出消息進行處理。
這樣,系統(tǒng)可以在流量較低時處理請求,避免了系統(tǒng)因瞬時高并發(fā)而崩潰。
例如,在電商平臺中,用戶下單后,可以將支付請求通過消息隊列推送到處理隊列,由后臺異步處理支付請求,避免高并發(fā)時同步處理的壓力。
以及,在秒殺活動中,用戶的請求量可能會激增,消息隊列可以幫助將大量請求排入隊列中,逐步處理,以避免系統(tǒng)崩潰。