無論是電商平臺的 “雙 11”“618” 大促，還是 12306 的春運搶票時刻，抑或是在線直播的高峰時段，都對系統(tǒng)的并發(fā)處理能力提出了極高的要求。當每秒數(shù)以千萬計的請求如潮水般涌來時，系統(tǒng)架構的設計就顯得尤為關鍵，它直接決定了系統(tǒng)能否穩(wěn)定、高效地運行，為用戶提供良好的體驗。若架構設計不合理，系統(tǒng)可能會陷入卡頓、崩潰的困境，導致用戶流失、業(yè)務受損。

關鍵指標知多少 （一）QPS、TPS、并發(fā)數(shù)與響應時間

在開始設計千萬級并發(fā)系統(tǒng)架構之前，我們首先需要明確一些關鍵的性能指標，它們是衡量系統(tǒng)性能的重要依據(jù)，就如同航海中的燈塔，指引著我們的架構設計方向。

QPS（Queries Per Second）即每秒查詢數(shù) ，它反映了系統(tǒng)每秒能夠處理的查詢請求數(shù)量。以搜索引擎為例，QPS 就是衡量其每秒能夠響應用戶搜索查詢的次數(shù)。對于電商系統(tǒng)來說，QPS 則體現(xiàn)了系統(tǒng)每秒處理商品查詢、訂單查詢等請求的能力。TPS（Transactions Per Second）即每秒事務數(shù)，一個事務通常是指一個客戶機向服務器發(fā)送請求，然后服務器做出反應的完整過程。比如在電商系統(tǒng)中，用戶下單購買商品這個操作，從用戶點擊下單按鈕，到系統(tǒng)完成庫存扣減、訂單記錄等一系列操作，就可以視為一個事務，TPS 則表示系統(tǒng)每秒能夠處理這樣完整事務的數(shù)量。

并發(fā)數(shù)是指系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶數(shù)量。在一個在線游戲中，并發(fā)數(shù)就是同時在線玩游戲的玩家數(shù)量；對于電商平臺，并發(fā)數(shù)則是同一時刻正在瀏覽商品、下單、支付等操作的用戶數(shù)。響應時間是指系統(tǒng)對請求作出響應的時間，從用戶角度來看，就是用戶發(fā)出請求后，等待系統(tǒng)返回結果所花費的時間。在移動應用中，用戶點擊一個按鈕，到界面刷新顯示出相應結果的時間間隔，就是響應時間。

這些指標相互關聯(lián)又相互制約。一般來說，QPS 和 TPS 越高，說明系統(tǒng)的處理能力越強；并發(fā)數(shù)越大，對系統(tǒng)的資源消耗也就越大；而響應時間越短，用戶體驗就越好。但在實際系統(tǒng)中，很難同時做到高 QPS、高并發(fā)數(shù)和短響應時間，需要我們在架構設計中進行權衡和優(yōu)化。

（二）用 2/8 法則預估流量

在設計千萬級并發(fā)系統(tǒng)時，準確預估流量是至關重要的一步。這里我們可以采用經(jīng)典的 2/8 法則（也稱為帕累托法則）來進行流量預估。

假設我們要設計一個千萬級用戶的電商網(wǎng)站，根據(jù) 2/8 法則，我們可以大致認為每天有 20% 的用戶會活躍訪問網(wǎng)站。那么每日活躍用戶數(shù)大約為 1000 萬 ×20% = 200 萬。通常每個用戶在一次訪問中會進行多次操作，假設平均每個用戶每次訪問有 30 次點擊操作（包括瀏覽商品、查看詳情、加入購物車等），那么每日的總點擊量（PV，Page View）大約為 200 萬 ×30 = 6000 萬。

一天有 24 小時，根據(jù) 2/8 法則，大部分用戶的活躍時間集中在 20% 的時間段內(nèi)，即 24×20% = 4.8 小時，我們近似認為是 5 小時。而在這 5 小時內(nèi)，又會有 80% 的點擊量集中出現(xiàn)，即 6000 萬 ×80% = 4800 萬點擊量。那么在這 5 小時的活躍訪問期內(nèi)，平均每秒的請求量大約為 4800 萬 ÷（5×3600）≈2667 次。

但在實際情況中，這 5 小時內(nèi)還會出現(xiàn)高峰時段，比如在促銷活動開始的半小時內(nèi)，用戶請求量會急劇增加。根據(jù)線上經(jīng)驗，高峰訪問量通常是平均訪問量的 2 - 3 倍，我們假設按照 3 倍來計算，那么在高峰時段，每秒的請求量可能會達到 2667×3 ≈ 8000 次。通過這樣的預估，我們對系統(tǒng)可能面臨的流量有了一個較為清晰的認識，為后續(xù)的架構設計提供了重要的數(shù)據(jù)支持。

架構設計步驟 （一）從單體到高可用架構

在網(wǎng)站發(fā)展的初期，由于業(yè)務量較小，用戶訪問量相對較低，通常采用單體架構。單體架構就像一座功能齊全的獨棟別墅，將所有的業(yè)務功能都集成在一個應用程序中，應用服務器和數(shù)據(jù)庫緊密結合在一起。這種架構的優(yōu)點顯而易見，開發(fā)和部署都非常簡單，就像建造獨棟別墅，所有的設計和施工都相對容易把控。

然而，隨著業(yè)務的逐漸發(fā)展，用戶量不斷增加，單體架構的弊端也逐漸顯現(xiàn)出來。它就像一個不堪重負的巨人，開始出現(xiàn)各種問題。應用服務器和數(shù)據(jù)庫成為了單點故障，如果應用服務器出現(xiàn)故障，整個網(wǎng)站將無法訪問；如果數(shù)據(jù)庫出現(xiàn)故障，數(shù)據(jù)的存儲和讀取將受到影響，業(yè)務也會陷入停滯。就好比別墅的主要支撐結構出現(xiàn)問題，整個建筑就會面臨倒塌的危險。

為了解決這些問題，我們引入了初步的高可用架構。首先，將應用服務器進行集群化部署，就像建造了多棟相同的別墅，形成一個別墅群。通過負載均衡器，將用戶的請求均勻地分發(fā)到集群中的各個應用服務器上，這樣不僅可以提高系統(tǒng)的處理能力，還能實現(xiàn)應用服務器的冗余備份。當某一臺應用服務器出現(xiàn)故障時，負載均衡器會自動將請求轉發(fā)到其他正常的服務器上，確保服務的連續(xù)性。

同時，對數(shù)據(jù)庫采用主從架構，主數(shù)據(jù)庫負責數(shù)據(jù)的寫入操作，從數(shù)據(jù)庫則實時同步主數(shù)據(jù)庫的數(shù)據(jù)，并負責數(shù)據(jù)的讀取操作。這樣，即使主數(shù)據(jù)庫出現(xiàn)故障，從數(shù)據(jù)庫也可以繼續(xù)提供數(shù)據(jù)讀取服務，保證系統(tǒng)的部分功能正常運行。通過這些措施，系統(tǒng)的可用性得到了顯著提高，就像別墅群和備用支撐結構的結合，大大增強了系統(tǒng)的穩(wěn)定性和可靠性。

（二）業(yè)務垂直拆分

隨著業(yè)務的持續(xù)增長，研發(fā)團隊也在不斷擴大。此時，單塊系統(tǒng)就像一個龐大而復雜的迷宮，開發(fā)和維護的難度越來越大。不同業(yè)務模塊之間的代碼耦合度高，牽一發(fā)而動全身，一個小小的改動可能會引發(fā)一系列意想不到的問題。就像在迷宮中改變一條路徑，可能會導致整個迷宮的通行規(guī)則發(fā)生變化，讓人迷失方向。

為了提高開發(fā)效率，降低系統(tǒng)的復雜度，我們需要對業(yè)務進行垂直拆分。這就好比將一個大型商場按照不同的商品類別劃分成多個獨立的小店鋪，每個小店鋪專注于經(jīng)營一類商品。將單塊系統(tǒng)拆分為多個業(yè)務系統(tǒng)，每個業(yè)務系統(tǒng)專注于一個特定的業(yè)務領域，例如電商系統(tǒng)可以拆分為用戶系統(tǒng)、商品系統(tǒng)、訂單系統(tǒng)、支付系統(tǒng)等。每個小團隊負責一個業(yè)務系統(tǒng)的開發(fā)、維護和升級，他們可以獨立地進行技術選型、架構設計和功能迭代，就像每個小店鋪可以自主決定商品的進貨、陳列和銷售策略一樣。

這樣的垂直拆分使得業(yè)務邏輯更加清晰，團隊之間的職責分工更加明確，大大提高了開發(fā)效率和系統(tǒng)的可維護性。同時，不同業(yè)務系統(tǒng)之間通過接口進行通信，實現(xiàn)了業(yè)務的解耦，就像不同店鋪之間通過商場的通道進行貨物運輸和信息交流一樣，相互協(xié)作又互不干擾。

（三）分布式緩存抗讀壓

在高并發(fā)的場景下，數(shù)據(jù)庫就像一個繁忙的交通樞紐，承受著巨大的壓力。大量的讀請求如潮水般涌來，數(shù)據(jù)庫的處理能力很容易達到瓶頸，導致響應時間變長，系統(tǒng)性能下降。就像交通樞紐在高峰期時，車輛擁堵，通行速度變慢。

為了緩解數(shù)據(jù)庫的壓力，我們引入了分布式緩存，如 Redis 集群。分布式緩存就像一個高效的臨時倉庫，它遵循 2/8 法則，將經(jīng)常被訪問的數(shù)據(jù)（大約 80% 的讀請求所涉及的數(shù)據(jù)）存儲在內(nèi)存中，當用戶發(fā)起讀請求時，首先從緩存中獲取數(shù)據(jù)。如果緩存中存在所需數(shù)據(jù)，就可以直接返回給用戶，大大減少了對數(shù)據(jù)庫的訪問次數(shù)。據(jù)統(tǒng)計，在一些高并發(fā)的電商系統(tǒng)中，引入分布式緩存后，數(shù)據(jù)庫的讀壓力可以降低 80% 以上，系統(tǒng)的響應時間也可以縮短數(shù)倍。

Redis 集群通過將數(shù)據(jù)分片存儲在多個節(jié)點上，實現(xiàn)了數(shù)據(jù)的分布式存儲和高可用性。它支持多種數(shù)據(jù)結構，如字符串、哈希表、列表、集合等，可以滿足不同業(yè)務場景的需求。例如，在電商系統(tǒng)中，可以將商品信息、用戶信息、訂單信息等常用數(shù)據(jù)存儲在 Redis 緩存中，提高數(shù)據(jù)的讀取速度。通過分布式緩存的引入，系統(tǒng)的讀性能得到了極大的提升，就像在交通樞紐旁邊建立了多個臨時停車場，減輕了交通樞紐的壓力，提高了交通的流暢性。

（四）數(shù)據(jù)庫主從架構與讀寫分離

在高并發(fā)系統(tǒng)中，數(shù)據(jù)庫的性能優(yōu)化至關重要。除了引入分布式緩存，數(shù)據(jù)庫主從架構與讀寫分離也是提升數(shù)據(jù)庫性能的重要手段。

數(shù)據(jù)庫主從架構就像一個主從協(xié)作的團隊，主數(shù)據(jù)庫負責處理寫操作，如數(shù)據(jù)的插入、更新和刪除。從數(shù)據(jù)庫則通過復制主數(shù)據(jù)庫的二進制日志，實時同步主數(shù)據(jù)庫的數(shù)據(jù)，并負責處理讀操作，如數(shù)據(jù)的查詢。這樣的分工可以將讀寫操作分離，避免讀寫沖突，提高數(shù)據(jù)庫的并發(fā)處理能力。

以電商系統(tǒng)為例，當用戶下單購買商品時，寫操作（如訂單信息的插入、庫存的扣減等）會被發(fā)送到主數(shù)據(jù)庫進行處理。主數(shù)據(jù)庫完成寫操作后，會將相應的二進制日志記錄下來，從數(shù)據(jù)庫通過 I/O 線程監(jiān)聽主數(shù)據(jù)庫的二進制日志更新，一旦發(fā)現(xiàn)有新的日志記錄，就會將其拷貝到自己的中繼日志中，然后通過 SQL 線程從中繼日志中讀取事件，并在自己的數(shù)據(jù)庫中重放這些事件，從而實現(xiàn)數(shù)據(jù)的同步。

當用戶查詢訂單信息或商品信息時，讀操作會被路由到從數(shù)據(jù)庫。由于從數(shù)據(jù)庫可以有多個，通過負載均衡器可以將讀請求均勻地分發(fā)到各個從數(shù)據(jù)庫上，這樣不僅可以提高讀操作的效率，還能減輕主數(shù)據(jù)庫的壓力。據(jù)測試，在一個具有一主三從架構的數(shù)據(jù)庫系統(tǒng)中，讀操作的性能相比單數(shù)據(jù)庫可以提升 3 - 5 倍，大大提高了系統(tǒng)的整體性能。

（五）其他優(yōu)化策略

除了上述的架構設計和優(yōu)化措施，還有一些其他的優(yōu)化策略可以進一步提升系統(tǒng)的性能。

在磁盤數(shù)據(jù)訪問方面，頁緩存是一種重要的優(yōu)化技術。操作系統(tǒng)會將磁盤中的數(shù)據(jù)以頁為單位緩存到內(nèi)存中，當應用程序需要讀取數(shù)據(jù)時，首先會在頁緩存中查找，如果命中，則可以直接從內(nèi)存中讀取，避免了磁盤 I/O 操作，大大提高了數(shù)據(jù)讀取的速度。例如，在一個文件存儲系統(tǒng)中，通過頁緩存技術，數(shù)據(jù)的讀取速度可以提高數(shù)倍。

順序讀寫也是一種優(yōu)化策略，相比于隨機讀寫，順序讀寫可以減少磁盤尋道時間，提高 I/O 性能。在設計數(shù)據(jù)庫表結構和存儲方式時，應盡量保證數(shù)據(jù)的存儲和讀取是順序的。此外，使用 SSD（固態(tài)硬盤）代替?zhèn)鹘y(tǒng)的機械硬盤也是提升磁盤性能的有效方法，SSD 具有更快的讀寫速度和更低的延遲，能夠顯著提高系統(tǒng)的 I/O 性能。

在內(nèi)存優(yōu)化方面，內(nèi)存緩存是常用的手段。將熱點數(shù)據(jù)存儲在內(nèi)存中，可以減少對磁盤和數(shù)據(jù)庫的訪問，提高系統(tǒng)的響應速度。池化技術也是一種重要的內(nèi)存優(yōu)化策略，如數(shù)據(jù)庫連接池、線程池等。通過池化技術，可以預先創(chuàng)建一定數(shù)量的資源對象，并將其緩存起來，當應用程序需要使用這些資源時，可以直接從池中獲取，而不需要重新創(chuàng)建，這樣可以減少資源的創(chuàng)建和銷毀開銷，提高系統(tǒng)的性能和資源利用率。

案例分析

以淘寶為例，在其發(fā)展歷程中，經(jīng)歷了多次架構演進以應對不斷增長的并發(fā)需求。早期淘寶采用單體架構，隨著用戶量和業(yè)務量的迅速攀升，單體架構的局限性逐漸凸顯。為了提升系統(tǒng)的可用性和性能，淘寶引入了負載均衡和應用服務器集群，實現(xiàn)了初步的高可用架構。

隨著業(yè)務的進一步拓展，淘寶對業(yè)務進行了垂直拆分，將系統(tǒng)拆分為多個獨立的業(yè)務模塊，如商品、訂單、用戶等，每個模塊都有獨立的數(shù)據(jù)庫和服務，提高了系統(tǒng)的可維護性和擴展性。為了應對高并發(fā)場景下的讀壓力，淘寶大規(guī)模使用分布式緩存，如 Redis 集群，將大量的熱點數(shù)據(jù)存儲在緩存中，極大地減輕了數(shù)據(jù)庫的讀壓力。

在數(shù)據(jù)庫方面，淘寶采用了主從架構和讀寫分離技術，通過多個從數(shù)據(jù)庫來分擔讀請求，同時對寫操作進行優(yōu)化，保證了數(shù)據(jù)的一致性和系統(tǒng)的高性能。此外，淘寶還在磁盤數(shù)據(jù)訪問、內(nèi)存優(yōu)化等方面進行了大量的技術創(chuàng)新和優(yōu)化，如使用 SSD 硬盤提高 I/O 性能，采用內(nèi)存緩存和池化技術減少資源開銷。

通過這一系列的架構設計和優(yōu)化，淘寶成功地應對了每年 “雙 11” 等大促活動帶來的千萬級并發(fā)挑戰(zhàn)。在 “雙 11” 當天，系統(tǒng)能夠穩(wěn)定地處理海量的用戶請求，實現(xiàn)高效的商品展示、下單、支付等操作，為用戶提供了流暢的購物體驗，也為電商行業(yè)的高并發(fā)系統(tǒng)架構設計提供了寶貴的經(jīng)驗和借鑒。