高并發(fā)系統(tǒng)的藝術(shù)：如何在流量洪峰中游刃有余

前言

我們常說的三高，高并發(fā)、高可用、高性能，這些技術(shù)是構(gòu)建現(xiàn)代互聯(lián)網(wǎng)應(yīng)用程序所必需的。對于京東618備戰(zhàn)來說，所有的中臺系統(tǒng)服務(wù)，無疑都是圍繞著三高來展開的。而對于京東龐大的客戶群體，高并發(fā)的要求尤為重要。用戶對在線服務(wù)的需求和期望不斷提高，系統(tǒng)的并發(fā)處理能力成為衡量其性能和用戶體驗的關(guān)鍵指標(biāo)之一。高并發(fā)系統(tǒng)不僅僅是大型互聯(lián)網(wǎng)企業(yè)的專利，對于任何希望在市場中占據(jù)一席之地的公司來說，能夠處理大量并發(fā)請求的能力都是至關(guān)重要的。

高并發(fā)系統(tǒng)的設(shè)計和實現(xiàn)是一個復(fù)雜且多層次的過程，涉及到硬件資源的合理利用、系統(tǒng)架構(gòu)的精心設(shè)計、并發(fā)控制技術(shù)的應(yīng)用以及性能調(diào)優(yōu)等多個方面。無論是電商平臺在大促期間應(yīng)對突發(fā)流量，還是社交媒體在熱點事件發(fā)生時的流量激增，抑或是金融系統(tǒng)在交易高峰期的平穩(wěn)運(yùn)行，都需要一個高效、穩(wěn)定、可擴(kuò)展的高并發(fā)系統(tǒng)作為支撐。

接下來我通過一張思維導(dǎo)圖展開我的分享，幫大家梳理一下一個高并發(fā)系統(tǒng)所需要考慮的技術(shù)點。

單機(jī)維度

在單機(jī)維度上， 我們一般分為硬件維度和代碼維度兩個方向考慮。硬件維度比較簡單，就是提升單機(jī)的硬件性能和網(wǎng)絡(luò)帶寬。而代碼維度，則是在高并發(fā)系統(tǒng)架構(gòu)設(shè)計時，最容易被大家忽視的，尤其是大量的脫離一線研發(fā)并進(jìn)化成PPT架構(gòu)師的今天，單機(jī)維度基本不在考量范圍。

但不積跬步無以至千里，有的時候單機(jī)接口的的性能優(yōu)化，會帶來很高的經(jīng)濟(jì)成本價值。在代碼維度，我這里重點介紹一種情況，關(guān)于多線程和異步方法。

a. 多線程和異步方法的誤區(qū)

關(guān)于多線程和異步方法的概念，我再面試候選人的時候，發(fā)現(xiàn)很多人對此都有誤區(qū)。在此，我先詳細(xì)的一下他倆的概念：

多線程：多線程是指在一個進(jìn)程中可以同時運(yùn)行多個線程，每個線程執(zhí)行不同的任務(wù)。Java通過java.lang.Thread類和java.util.concurrent包提供了多線程編程的支持。多線程的主要目的是為了充分利用CPU資源，提高程序的執(zhí)行效率。

異步方法：異步方法是指在調(diào)用某個方法時，不需要等待該方法執(zhí)行完成即可繼續(xù)執(zhí)行后續(xù)代碼。Java通過CompletableFuture和異步回調(diào)機(jī)制提供了異步編程的支持。異步方法的主要目的是為了提高系統(tǒng)的響應(yīng)能力和資源利用率。

b. 多線程能夠解決高并發(fā)場景么

當(dāng)大家了解了多線程和異步方法的概念后，那么我們就可以認(rèn)真思考一下，多線程一定能提升系統(tǒng)的并發(fā)能力么？

我的結(jié)論是：多線程可以提升部分服務(wù)的并發(fā)能力，但并不能顯著提高性能。

首先我們先了解，Tomcat的Servlet機(jī)制是基于多線程實現(xiàn)的，而如果你在單次請求中在此開辟線程池進(jìn)行多線程處理，在一定的并發(fā)情況下，你可能只是改善了單次請求的TP99，但無法有效提升系統(tǒng)的并發(fā)能力。因為多線程的性能提升與CPU核心數(shù)密切相關(guān)。如果系統(tǒng)只有一個CPU核心，那么多個線程只能在該核心上輪流執(zhí)行，無法實現(xiàn)真正的并行處理。而我們的宿主機(jī)一般也就是8C或者16C，在面單機(jī)上千的QPS請求時，多線程只會增加CPU上下文切換的負(fù)擔(dān)。

舉個簡單并且常見的例子，批量下單接口。我們常見的做法就是在批量下單接口中開辟線程池，然后建個多個下單在線程池中并行處理。這樣做的結(jié)果是，在請求量低的情況下，效果還是可以的，單次請求的QPS也會很低，但如果單機(jī)面臨每秒上千次的下單請求，這種實現(xiàn)方式就會出現(xiàn)問題。最直觀的觀察，可以通過TP99的監(jiān)控曲線發(fā)現(xiàn)，就是請求量跟TP99呈現(xiàn)嚴(yán)重的正相關(guān)性。

而真正有效的提升下單接口的并發(fā)能力，是通過異步方式實現(xiàn)。但異步方式又會增加系統(tǒng)的設(shè)計復(fù)雜度，比如下單失敗，異步回調(diào)設(shè)計和數(shù)據(jù)一致性設(shè)計等等，也在考量范圍之內(nèi)，這里就不詳細(xì)展開說明。

c. 小結(jié)

多線程和異步方法是Java開發(fā)中兩種重要的并發(fā)處理技術(shù)，它們在提高系統(tǒng)性能和響應(yīng)能力方面各有優(yōu)勢。多線程通過并行處理任務(wù)，充分利用CPU資源，適用于CPU密集型任務(wù)和需要并行處理的場景。異步方法通過非阻塞I/O操作和異步回調(diào)機(jī)制，提高系統(tǒng)的響應(yīng)能力和資源利用率，適用于I/O密集型任務(wù)和事件驅(qū)動架構(gòu)。

此外當(dāng)然還有大家經(jīng)常樂于討論的JVM調(diào)優(yōu)問題，基于JVM調(diào)優(yōu)，包括垃圾回收器的選擇，參數(shù)的合理優(yōu)化，當(dāng)然，還有一點，其實大家平時關(guān)注不多，就是采用更高版本的JDK和更新的Spring框架，因為高版本的框架會對性能本身有不錯的優(yōu)化。關(guān)于這點，我在另一篇文章中有重點介紹：性能加速包: SpringBoot 2.7&JDK 17,你敢嘗一嘗嗎

多機(jī)維度

在多機(jī)維度考慮系統(tǒng)的高并發(fā)性能，應(yīng)該是大家最長能夠想到的場景了，也是架構(gòu)師們最熱衷討論的點。

首先是對系統(tǒng)的拆分角度來說，第一個是單體應(yīng)用的水平擴(kuò)展問題，就是我們所說的負(fù)載均衡集群，換成我們經(jīng)常聽到的一個詞： 擴(kuò)容。擴(kuò)容一般針對負(fù)載均衡集群進(jìn)行水平擴(kuò)展，用于解決單機(jī)無法承載高并發(fā)的情況，這也是互聯(lián)網(wǎng)公司解決高并發(fā)場景的最常用手段，就比如每次雙十一或者618前夕，我們都會成倍的擴(kuò)容我們的服務(wù)實例。

對系統(tǒng)的另一個拆分角度，叫做垂直拆分，也就是我們常見的分布式系統(tǒng)。比如按照領(lǐng)域劃分，我們將一個大的單體服務(wù)，拆分成不同的子領(lǐng)域系統(tǒng)，然后每個子領(lǐng)域系統(tǒng)單獨承擔(dān)各自的流量，而不會相互影響。還比如說長江的CQRS設(shè)計架構(gòu)，翻譯過來是指令查詢分離的設(shè)計方式，通過查詢和指令服務(wù)拆分，來講高并發(fā)的查詢場景單獨拆分出來進(jìn)行設(shè)計。

既然采用了分布式的微服務(wù)架構(gòu)，那么分布式系統(tǒng)的一些常見痛點也是高并發(fā)要考慮的，比如熔斷，降級，限流，超時等設(shè)計，這些本身是為了增強(qiáng)分布式系統(tǒng)的魯棒性，從而間接的增強(qiáng)系統(tǒng)的高并發(fā)承載能力。關(guān)于微服務(wù)架構(gòu)，在此處不再贅述，有興趣的，可以看我的另一篇文章:【實踐篇】教你玩轉(zhuǎn)微服務(wù)--基于DDD的微服務(wù)架構(gòu)落地實踐之路

垂直維度

所謂垂直維度，是為了區(qū)分于單機(jī)維度和多機(jī)維度的，垂直的意思是針對一個業(yè)務(wù)系統(tǒng)在系統(tǒng)層級的垂直劃分，包括業(yè)務(wù)應(yīng)用和數(shù)據(jù)庫。要知道，很多高并發(fā)場景，不管是寫場景還是讀場景，當(dāng)數(shù)據(jù)庫維度出現(xiàn)瓶頸，擴(kuò)容就不想業(yè)務(wù)應(yīng)用服務(wù)那么簡單了，所以要區(qū)分來說。

a. 業(yè)務(wù)應(yīng)用

唯物辯證法中有一個重要概念，就是一切從實際出發(fā)，具體問題具體分析。對于高并發(fā)系統(tǒng)的構(gòu)建，雖然有通用的手段和方法論，但沒有統(tǒng)一的落地方案，必須根據(jù)具體的業(yè)務(wù)應(yīng)用場景進(jìn)行分析和設(shè)計。比如你的系統(tǒng)是高并發(fā)讀還是高并發(fā)寫，處理思路也是完全不一樣的。當(dāng)然常見的手段和方法論核心包括兩點：緩存和異步。但具體到相應(yīng)的業(yè)務(wù)，需要仔細(xì)思考緩存邏輯怎么設(shè)計，異步流程怎么設(shè)計，如何保證數(shù)據(jù)一致性等等。

這塊我有一個項目案例，就是在SAAS商城中秒殺場景下，如何設(shè)計高性能庫存扣減邏輯，我將這塊內(nèi)容寫在了我另一篇文章里：高并發(fā)場景下的庫存管理，理論與實戰(zhàn)能否兼得？

b. 數(shù)據(jù)庫

在存儲媒介這塊其實高并發(fā)是不好設(shè)計的。比如關(guān)系型數(shù)據(jù)庫MySQL, 在進(jìn)行擴(kuò)展要比業(yè)務(wù)應(yīng)用復(fù)雜不少，涉及到的就是數(shù)據(jù)庫的分庫分表邏輯。

這塊可以參考之前我寫過的一篇文章：分而治之--淺談分庫分表及實踐之路。

而對于讀場景下的高并發(fā)請求，還有一種最常見的處理手段，就是異構(gòu)存儲介質(zhì)，實現(xiàn)讀寫分離，最常見的就是MySQL關(guān)系型數(shù)據(jù)庫負(fù)責(zé)寫，ES這種文檔類數(shù)據(jù)庫負(fù)責(zé)讀。而他的技術(shù)難點則在于數(shù)據(jù)的同步和數(shù)據(jù)一致性上。

審核編輯 黃宇