前言

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

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

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

單機維度

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

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

a. 多線程和異步方法的誤區

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

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

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

b. 多線程能夠解決高并發場景么

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

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

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

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

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

c. 小結

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

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

多機維度

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

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

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

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

垂直維度

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

a. 業務應用

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

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

b. 數據庫

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

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

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

審核編輯 黃宇