前言

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

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

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

單機維度

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

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

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

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

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

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

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

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

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

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

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

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

c. 小結

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

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

多機維度

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

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

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

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

垂直維度

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

a. 業(yè)務應用

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

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

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

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

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

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

審核編輯 黃宇