（篇幅較長，建議大家先收藏再看哦~）

在初步地學習并掌握了基礎的編程之后，如何提高編程能力是每個開發者關心的問題。對于 Java 的學習者來說，高并發是每個開發者技術進階的必經之路。但是高并發的技術要求和業務場景本身就是比較復雜的，這就會給大家的學習之路帶來一定的難度。

下面我們帶大家了解高并發系統的應用場景、市場需求以及目前市面上比較成熟的大型互聯網的系統架構基線是怎樣的，讓大家對于高并發有一個初步地認識，了解一些復雜業務場景需求下的高并發定制化應對策略，以及一些常見的高并發環境下的解決方案。

要點

• 大型系統的技術基石-高并發

• 系統分析原則

• 系統設計要點

• 大型系統架構設計

大型系統的技術基石-高并發

目前互聯網分布式系統架構設計中必須得考慮高并發因素的影響，我們給它一個定義的話它通常是指通過設計來保證系統能夠同時并行處理很多的請求。小到門戶網站的并發閱讀量、在線聊天功能，大到春運期間 12306 官網的并發購票業務、每年的雙十一電商大促時的并發交易量、電商秒殺、除夕夜微信紅包的并發等，這些都體現了現實業務開發的高并發技術的剛性需求。

在雙十一等電商大促活動之后，除了屢創新高的交易額外，還有一個看點就是各大電商平臺整點交易的并發量。很顯然，對于高并發的掌握能力在一定程度上反映了一個電商平臺的技術水平，往往我們都對于一個能抗得住高并發的系統格外的青睞。一些國內外的互聯網企業都在頻繁地推出各種高并發相關的新技術框架，由此可見對于高并發的極致追求一直是各大互聯網企業不斷挑戰、樂此不疲的研究方向。

“系統繁忙，請稍后再試”等異常反饋相信大家都在生活中碰到過，高并發技術是很重要的，但是也存在著巨大的技術挑戰和提升的價值空間。它是一個廣義的概念可以包含架構設計、SOA 面向服務的架構、分布式、微服務、數據處理、多線程等很多細分出來的知識。

現在給大家從技術的角度簡要地介紹一下如何處理高并發的請求。

例如，電商的秒殺活動會帶來非常大的高并發請求，為了避免超額的高并發請求沖垮電商的服務器，就需要對所有的并發請求進行處理。一般而言，可以先通過驗證碼和 IP 限制等手段攔截非法的用戶請求，然后搭建服務集群，將合法的并發請求進行分流。之后還可以在服務器內部設置最大的連接數、最大并發數等服務參數，并通過消息隊列對海量的并發請求進行削峰填谷處理。此外，為了讓數據庫穩定地處理高并發請求，還需要通過緩存中間件減少用戶請求數據庫的次數，并通過服務降級等策略減輕高并發峰值期間對系統的訪問壓力。最后，為了在極端情況下仍然能夠保障數據的安全性能，還需要搭建數據庫集群并設置合理的隔離機制。由此可見，高并發貫穿在項目設計的方方面面，從網關到服務器開發再到數據設計等環節都需要考慮高并發情況下的應對策略。

大家在學習過程中一定要在看懂文案、讀懂代碼的基礎上多實踐，多輸出，這樣子才可以后期自己實現“寫出來”。不要只是動眼、動耳但是不動手。希望大家參與到實踐中來，多練習，多總結。

系統分析原則

在市面上存在各種優秀的軟件系統，他們都遵循著相同的設計原則。大型的系統在設計的時候需要重點考慮一些原則和設計要點，這也是我們在這里想要強調的，這些原則會對系統架構的演進方案和具體的架構設計提供基礎的支持，這也是我們作為系統開發設計人員在設計一個系統剛開始需要掌握的理論基礎。

開發大型系統時，我們除了根據業務需求實現相應的功能模塊外，還需要從高性能和高可用等多個維度來思考如何對系統進行設計，遵循高并發、容錯性和可擴展等多個設計分析原則是我們重要需要考慮的。

高并發原則

高并發是每個大型項目都無法回避的問題，保證項目在高并發的環境下正常運行可以通過垂直擴展和水平擴展來實現，我們簡述一下垂直和水平擴展。

垂直擴展：
直接通過提升單機的性能的層面去升級硬件或者軟件技術，可以用一個比喻來說明，比如當一個小牛無法拉動貨物的時候，就可以將小牛換成體能強壯的大牛。

水平擴展：
通過增加服務器的節點個數來橫向擴展系統的性能，這也是分布式的一個說明方式，還是上面的這個比喻，當一頭牛無法拉動貨物的時候，就可以把貨物進行拆分，然后用多頭牛去拉這些貨物，或者用多頭牛一起去拉這批貨物。

對比上面這兩種方案，我們可以很顯然地發現，處置擴展是最快的方法，只需要購買性能更加強大的硬件設備就可以迅速地提升性能，但是單機的能力還是有限的，如果貨物很多的話，比如我們用一座山來類比，一頭牛再厲害也是拉不動一座小山的，因此，大型互聯網系統對于高并發的最終解決方案是水平擴展。

從技術層面講，可以使用緩存來減少對數據庫的訪問，用熔斷或者降級來提高響應的速度，通過流量削峰等手段在項目的入口限流，先拆分項目或者使用微服務技術快速構建功能模塊，然后再用 Spring Cloud 或 Dubbo 等來統一治理這些模塊，通過中間件搭建基于讀寫分離的高可用的數據庫集群等。在系統的測試階段還可以使用 JProfiler 等工具進行性能分析，尋找性能瓶頸，從而有針對性地優化。

衡量高并發的常見指標包括：響應時間、吞吐量或 QPS(Query per Second，每秒查詢率)、并發用戶數等。

容錯原則

如果高并發使用不當的話，就容易造成各種邏輯混亂的情景，因此我們就需要對各種潛在的問題做好預案，也就是要確保系統要擁有一定的容錯性。比如使用 Spring Boot 和 Redis 來實現分布式緩存，使用 MQ 實現分布式場景下的事務一致性，使用 MQ、PRG 模式、Token 等解決重復提交的問題，使用“去重表”實現操作的冪等性，使用集群或 Zookeeper 解決失敗遷移的問題。

在分布式系統中，網絡時延也是不可避免的，一般情況可以在長連接的情況下通過“心跳監測機制”來處理，我們下面簡單闡述一下心跳監測機制。

在正常的網絡環境下面，當用戶點擊了手機上某個 App 的“退出”按鈕后，就會調用服務端的 exit()等退出方法，從而注銷掉用戶的狀態，如果用戶的手機信號中斷、關機或者處于飛行模式話該如何判斷用戶的狀態呢？除了通過 Session 有效時長來進行判斷外，就可以通過心跳檢測來判斷，客戶端每隔 60s 向服務端發送一次心跳，如果服務端能夠接收到的話就說明客戶端的狀態正常，如果服務端沒有接收到就等待客戶端下一個 60s 發來的心跳，如果連續 N 次都沒有接收到來自某個客戶端的心跳的話就可以認定此客戶端已經斷線了。

為了進一步提高系統的容錯性，還可以預先采用“隔離的手段”，對于秒殺等可預知時間的流量暴增情況，就可以提前將秒殺隔離成獨立的服務，防止秒殺帶來的流量問題影響到系統中的其他服務，當然如果預計的流量的增加不是很多的話，也可以使用多級緩存來解決高并發問題。

CAP 原則

分布式系統包含了多個節點，多個節點的數據之間應該如何實現同步，在數據同步的時候需要考慮哪些因素呢？CAP 原則是理解和設計分布式系統的基礎，包含了 C(Consistency)一致性、A(Availability)可用性、P(Partition tolerance)分區容錯性三個部分。

一致性 C：
在同一時刻所有節點中的數據都是相同的，當客戶端發出讀請求之后，立刻能從分布式的所有節點中讀取到相同的數據。

可用性 A：
在合理的時間范圍內，系統能夠提供正常的服務，不會出現異常或者超時等不可用的現象。

分區容錯性 P：
當分布式系統中的一個或者多個節點發生網絡故障（網絡分區），從而脫離整個系統的網絡環境時，系統仍然能夠提供可靠的服務，也就是說，當部分節點故障時，系統還是可以正常運行的。

著名的 CAP 原則是在任何一個分布式系統中，C、A、P 三者不可兼得，最多只能同時滿足兩個。為什么這么說呢，我們可以看一下下面的這個圖。

如果客戶端發出了寫的請求，成功更新了服務 A，但由于網絡故障沒有更新服務 B，那么下一次客戶端的讀請求如何處理呢？此時要么犧牲數據的一致性，要么在設計階段就嚴格要求數據必須得一致，當像任何一個服務中寫失敗的時候，就撤銷全部的寫操作并提示失敗，即犧牲了寫操作的可用性。

一般而言分布式肯定會遇到網絡問題的，分區容錯性是最基本的要求，因此在實際設計的時候往往是在一致性和可用性之間根據具體的業務來權衡。

冪等性原則

上面提到了網絡問題，網絡問題會對用戶的調用服務的次數造成影響，我們看下面的由于返回失敗而導致用戶重復支付的例子：

在分布式系統中，如果模塊 A（如商品服務）已經成功調用了模塊 B（如支付服務），但是由于網絡故障等問題造成模塊 B 在返回時出錯，就可能導致用戶因為無法感知模塊 A 是否成功執行從而多次主動執行模塊 A，造成模塊 A 的重復執行。例如，當用戶在購買商品你時，如果在點擊“支付”按鈕之后不能看到“支付成功”等提示，就可能再次點擊“支付”按鈕造成用戶多次支付的異常行為。然而實際上，“支付”操作在用戶第一次點擊時就已經成功執行了，只是在給用戶返回結果時出了錯。所以我們需要考慮某個觸發的動作會不會被重復執行的問題，使用冪等性原則就是對調用服務的次數進行的一種限制，即無論對某個服務提供的接口調用多次或者是一次，其結果都是相同的。

對于分布式或者微服務系統，為了實現冪等性，可以在寫操作之前，先通過執行讀操作來實現。還是以上面提到的案例為例，當商品服務調用支付服務時，嚴格按照蝦米阿尼的步驟執行就可以實現冪等性：

• 讀操作：查詢支付服務中的支付狀態（已支付或未支付）。

• 在“去重表”中查詢‘“1”中的 ID 是否存在。

• 如果存在，直接返回結果，如果不存在，再執行核心操作如支付，并將“1”中的 ID 存入“去重表”中，最后返回結果。

實現冪等性的方法還可以通過 CAS 算法、分布式鎖、悲觀鎖等方式。

特殊的是查詢和刪除是不會出現冪等性問題的，查詢一次或者多次，刪除一次或者多次的結果都是一樣的。

除了冪等性外，還需要注意表單重復提交的問題，冪等性是由于網絡等故障，用戶不知道第一次操作是否成功，因此發送了多次重復的操作，意圖在于確保第一次的操作成功，而表單重復提交是指用戶已經看到了第一次操作成功的結果，但是由于誤操作或者其他原因點擊了“刷新頁面”等功能按鈕，導致多次發送相同的請求。可通過 Token 令牌機制、PRG 模式、數據庫唯一約束等方法避免表單的重復提交問題。

可擴展原則

項目的規模會隨著用戶的數量的增加而增大，因此大型系統務必在設計的時候就要考慮到項目的擴展解決方案，可擴展原則要從項目架構、數據庫設計、技術選型和編碼規范等多方面考量。例如，我們可以使用面向接口、前后端分離以及模塊化的編程風格，采用無狀態化服務，使用高內聚低耦合的編程規范等，力爭在設計時預留一些后期擴展時可能會使用到的接口，或者提前設計好項目擴展的解決方案。下面我們給大家列舉了一些可擴展原則實現的具體措施：

• 定義項目插件的統一頂級接口，在擴展功能時使用方便擴展的集成自定義插件。

• 使用無狀態化的應用服務，避免開發后期遇到 Session 共享等數據同步問題。

• 使用 HDFS 等分布式文件系統，在存儲容量不足時迅速通過增加設備來擴容。

• 合理地設計了數據庫的分庫分表策略及數據異構方式，就能快速進行數據庫擴容。

• 使用分布式或微服務架構，快速開發并增加新的功能模塊。

如果在系統設計時就考慮了可擴展的各種手段，就能在系統想遇到瓶頸或業務需求改變時快速做出更改，從而大幅提高開發的效率。

可維護原則與可監控原則

一個設計優良的項目不僅能夠加速項目的研發，而且還可以在項目竣工后提供良好的可維護性與可監控性，因此在系統的設計階段，要考慮項目的可維護原則與可監控原則。

可維護原則是指系統在開發完畢后，維護人員能夠方便地改進或者修復系統中存在的問題。可維護原則包含了可理解性、可修改性和可移植性等多方面因素。通常可以通過以下 5 個方面來實現項目的可維護原則。

• 項目的日志記錄功能完善，易于追溯問題，統計操作的情況。

• 有 BugFree 等 Bug 管理工具。

• 有豐富的項目文檔和注釋。

• 統一的開發規范。例如變量名盡量做到見名知意、少用縮寫、代碼縮進規范、面向接口編程、編碼與配置分離、適當地使用設計模式等。

• 使用模塊化的編程模式。

可監控原則是指對系統中的流量、性能、服務、異常等情況進行實時的監控。理想的狀態是既有儀表盤形狀的圖形化全局監控數據，又有基線型用于顯示各個時間段的歷史軌跡，還有一些關鍵業務的變動對比圖（對比業務變更前后，用戶流量的變動情況等）。

此外還需要對項目中的一些關鍵技術做性能監控，確保新技術的引入的確能帶來性能的提升。

系統設計階段提前規避問題

上面闡述了關于系統設計時的一些需要注意的原則，如果能夠預先看到的話，就需要我們在設計層面提前解決，這樣子就會給后期的開發帶來很大的便捷。我們在這里簡單給大家介紹幾個景點的問題，如果不注意的話將會導致后期的開發工作十分艱難，甚至會造成“推倒重來”的情形。

Session 共享問題

在 Web 項目中，Session 是服務端用于保存客戶端信息的重要對象。單系統中的 Session 對象可以直接保存在內存中，但是在分布式的或集群環境下，多個不同的節點就需要采取措施來共享 Session 對象，一般可以使用下面三種方式。

Session Replication

Session Replication 是指在客戶端第一次發出請求后，處理該請求的服務端就會創建一個與之對應的 Session 對象，用于保存客戶端的狀態信息，之后為了讓其他服務器也能保存一份此 Session 對象，就需要將此 Session 對象在各個服務端節點之間進行同步。

但是這個也會造成一定的問題就是嚴重的冗余，如果有多個用戶在同時訪問，那么每個服務節點中都會保存很多用戶的 Session 對象。服務節點的個數越多，Session 冗余的問題就越嚴重，因此這個方式只適用于服務節點比較少的場景。

Session Sticky

Session Sticky 是通過 Nginx 等負載均衡工具對各個用戶進行標記比如對 Cookie 進行標記，使每個用戶在經過負載均衡工具之后都請求固定的服務節點。

客戶端 A 和客戶端 B 的請求都被分別轉發到了不同的應用服務上面。因此各個服務中的 Session 就無需同步。但是這種做法也會有弊端，如果某個服務節點宕機，那么該節點上的所有 Session 對象都會丟失。

獨立 Session 服務器

除了 Session Replication 和 Session Sticky 兩種方式外，還可以將系統中所有的 Session 對象都存放到一個獨立的 Session 服務中，之后各個應用服務再分別從這個 Session 服務中獲取需要的 Session 對象。在大規模分布式系統中，推薦使用這種獨立的 Session 服務方式。這種方式在存儲 Session 對象時，既可以用數據庫，又可以使用各種分布式或集群存儲系統。

在使用了獨立的 Session 服務器之后，應用服務就是一種無狀態服務了，換句話說，此時的應用服務與用戶的狀態是無關的，無論是哪個用戶在什么時間發出的請求，所有的應用服務都會進行相同的處理。先從 Session 服務中獲取 Session 對象，再進行相同的業務處理。

有狀態服務是指不同的應用服務與用戶的狀態有著密切的關系，例如假設應用服務 A 中保存著用戶的 Session，應用服務 B 中沒有保存，之后如果用戶發出一個請求，經過 Nginx 轉發到了應用服務 A 中，那么就可以直接進行下單、結算等業務，而如果用戶的請求被 Nginx 轉發到了應用服務 B 中，就會提示用戶“請先登錄······”，類似這種不同應用服務因為對用戶狀態的持有情況不同，從而導致的執行方式不同就可以理解為“有狀態服務”。

“無狀態服務”具有數據同步、快速部署的優勢，但是也不能盲目地將其作為唯一的選擇，任何技術或者架構的選擇都得看具體的業務場景，如在小型項目中或僅有一個服務的項目中，就可以采用有狀態的服務來降低開發的難度，縮短開發的周期。

技術選型原則與數據庫設計

在做技術選型時，既要注意技術的性能，又要注意安全性，并預估這些技術是否有足夠長的生命力。我們在這里以 MySQL 數據庫為例，介紹一種數據庫的選型的思路。

各種版本的 MySQL 默認的并發連接數是一到兩百，單機可配置的最大連接數為 16384（一般情況下，由于計算機自身硬件的限制，單機實際能夠負載的并發數最多為一千左右）。因此高并發系統面臨的最大的性能瓶頸就是數據庫可，我們之前設計各種緩存的目的就是盡可能地減少對數據庫的訪問的。

除了在頁面、應用程序中增加緩存以外，我們還可以在應用程序和數據庫之間加一層 Redis 高速緩存，從而提高數據的訪問速度并且減少對數據庫的訪問次數，具體如下：

• 搭建高可用 Redis 集群，并通過主從同步進行數據備份、通過讀寫分離降低并發寫操作的沖突、通過哨兵模式在 Master 掛掉之后選舉新的 Master；

• 搭建雙 Master 的 MySQL 集群，并通過主從同步做數據備份；

• 通過 MyCat 對大容量的數據進行分庫/分表，并控制 MySQL 的讀寫分離；

• 通過 Haproxy 搭建 MyCat 集群；

• 通過 Keepalived 搭建 Haproxy 集群，通過心跳機制防止單節點故障；并且 Keepalived 可以生成一個 VIP，并用此 VIP 與 Redis 建立連接。

緩存穿透與緩存雪崩問題

緩存可以在一定程度上緩解高并發造成的性能問題，但在一些特定場景下緩存自身也會帶來一些問題，比較典型的就是緩存穿透與緩存雪崩問題。為了講解的方便，我們使用 MySQL 代指所有的關系型數據庫，用 Redis 代指所有數據庫的緩存組件。

緩存穿透

緩存穿透是指大量查詢一些數據庫中不存在的數據，從而影響數據庫的性能。例如 Redis 等 KV 存儲結構的中間件可以作為 MySQL 等數據庫的緩存組件，但如果某些數據沒有被 Redis 緩存卻被大量的查詢，就會對 MySQL 帶來巨大壓力。

我們在前面介紹過，單機 MySQL 最大能夠承受的并發連接數只有一千左右，因此無論是設計失誤（例如某個高頻訪問的緩存對象過期）、惡意攻擊（例如頻繁查詢某個不存在的數據），還是偶然事件（例如由于社會新聞導致某個熱點的搜索量大增）等，都可能讓 MySQL 遭受緩存穿透，從而宕機。

相信大家在理解了緩存穿透的原因后，解決思路就已經明確了，舉例如下。

• 攔截非法的查詢請求，僅將合理的請求發送給 MySQL。如，可以使用驗證碼、IP 限制等手段限制惡意攻擊，并用敏感詞過濾器等攔截不合理的非法查詢。

• 緩存空對象。如，假設在 iphone9 上市后，可能會導致大量用戶搜索 iphone9，但此時 Redis 和 MySQL 中還沒有 iphone9 這個詞。一種解決辦法就是，將數據庫中不存在的 iphone9 也緩存在 Redis 中，如 Key=iphone9,value=””。之后，當用戶再次搜索 iphone9 時，就可以直接從 Redis 中拿到結果，從而避免對 MySQL 的訪問，為了減少 Redis 對大量空對象的緩存，可以適當減少空對象的過期時間。

• 建立數據標識倉庫。將 MySQL 中的所有數據的 name 值都映射成 hash 值，例如可以將“商品表”中的商品名“iphone8”映射成 MD5 計算出來的 hash 值 b2dd48ff3e52d0796675693d08fb192e，然后再將全部 name 的 hash 值放入 Redis 中，從而構建出一個“數據庫中所有可查數據的 hash 倉庫”。之后，每次在查詢 MySQL 之前都會先查詢這個 hash 倉庫，如果要查詢數據的 hash 值存在于倉庫中，再進入 MySQL 做真實的查詢，如果不存在則直接返回。

緩存雪崩

除了緩存穿透以外，在使用緩存時還需要考慮緩存雪崩的情況。緩存雪崩是指由于某種原因造成 Redis 突然失效，從而造成 MySQL 瞬間壓力驟增，進而嚴重影響 MySQL 性能甚至造成 MySQL 服務宕機。以下是造成緩存雪崩的兩個常見原因：

• Redis 重啟；

• Redis 中的大量緩存對象都設置了相同的過期時間。

為了避免緩存雪崩的發生，可參考使用以下解決方案：

• 搭建 Redis 集群，保證高可用；

• 避免大量緩存對象的 key 集中失效，盡力讓過期時間分配均勻一些，例如，可以給各個緩存的過期時間乘一個隨機數；

• 通過隊列、鎖機制等控制并發訪問 MySQL 的線程數。

不同類型服務器的選擇

對于大型項目來說，為了保證較高的性能，至少需要三臺服務器：

• 應用服務器。

• 數據庫服務器。

• 文件服務器。

并且，不同類型的服務器對硬件的需求也各不相同，例如，應用服務器主要是處理業務邏輯，因此需要強大的 CPU 支持；數據庫服務器的性能依賴于磁盤檢索的速度和數據緩存的容量，因此需要速度較快的硬盤（如固態硬盤）和大容量的內存；文件服務器主要是儲存文件，因此需要大容量的硬盤。

集群服務與動靜分離

現在，雖然將服務器分成了應用服務器，數據庫服務器和文件服務器。但是每個子服務器僅僅只有一個，并且單一應用服務器能夠處理的請求連接是有限的，例如單個 Tomcat 最佳的并發量是 250 左右，如果并發的請求大于 250 就要考慮搭建 Tomcat 集群了（這里我們推薦可以使用 docker 快速搭建）。使用集群除了能解決負載均衡以外，還有另一個優勢：失敗遷移。當某一個應用服務器宕機時，其他應用服務器可以繼續處理客戶請求。

集群雖然有了，是否就適合存放全部數據并處理全部請求了呢？其實我們發現還可以進一步優化為“動靜分離”。下面闡述一下“動”與“靜”的概念。

靜：
如果是觀看電視劇/電影、微視頻、高清圖片等這種大文件的靜態請求，最好使用 CDN 將這些靜態資源部署在各地的邊緣服務器上，讓用戶可以就近獲取所需內容，以此降低網絡擁塞，提高用戶訪問響應速度。如果是 html、css、js 或小圖片等這類小文件的靜態資源，就可以直接緩存在反向代理服務器上，當用戶請求時直接給予響應。還可以用 webpack 等工具將 css、javascript、html 進行壓縮、組合，并將多個圖片合成一張雪碧圖，最終將靜態資源進行統一打包，從而優化前端資源的體積。

動：
如果是搜索商品、增、刪、改等動態請求，就需要訪問我們自己編寫并搭建的應用服務器。

之后，如果并發數繼續增加、項目繼續擴大，就可以使用分布式對項目進行拆分，接下來我們給大家具體介紹一下分布式系統的概念。

分布式系統

分布式系統可以理解為將一個系統拆分為多個模塊并部署到不同的計算機上，然后通過網絡將這些模塊進行整合，從而形成的一個完整系統。在實際應用時，分布式系統包含了分布式應用、分布式文件系統和分布式數據庫等類型，具體如下。

分布式應用：
將項目根據業務拆分成不同的模塊，各個模塊之間再通過 dubbo、Spring Cloud 等微服務架構或 SOA 技術進行整合。像這種根據業務功能，將項目拆分成多個模塊的方式，也成為垂直拆分。此外，我們也可以對項目進行水平拆分，例如可以將項目根據三層架構拆分成 View 層、Service 層、Dao 層等，然后將各層部署在不同的機器上。

分布式文件系統：
將所有文件分散存儲到多個計算機上。

分布式數據庫系統：
將所有數據分散存儲到多個計算機上。

分布式系統搭建完畢后，接下來可能遇到的問題是，如何提高數據的訪問速度？一種解決方案就是在應用服務器上使用緩存的方式，緩存分為本地緩存和遠程緩存。本地緩存的訪問速度最快，但是本地機器的內存容量、CPU 能力等有限。遠程緩存就是用于緩存分布式和集群上的數據，可以無限制地擴充內存容量、CPU 能力，但是遠程緩存需要進行遠程 IO 操作，因此緩存的速度相比本地緩存慢。

如果緩存沒有命中，就需要直接請求數據庫，當請求量較大時，就需要對數據庫進行讀寫分離，并且用主從同步對數據庫進行熱備份。如果是海量數據，除了可以用關系型數據庫搭建分布式數據庫以外，還可以使用 redis、Hbase 等 NoSQL 數據庫。相應的，在處理海量數據時，也推薦使用 ElasticSearch 或 Lucene 等搜索引擎，并用 Hadoop、Spark、Storm 等大數據技術進行處理。

值得一提的是，在微服務架構中，數據庫的使用比較靈活：每個微服務都可以有自己獨立的數據庫，或者多個微服務之間也可以交叉使用或共享同一份數據庫。并且這些服務之間可以使用 thrift、grpc 等 RPC 技術來進行整合。但要注意，使用 RPC 會給整個系統增加一層跨語言的中轉結構，因此必然會帶來一定程序的性能損耗。一般來講，進行 RPC 跨語言調用是一種不得已而為之的辦法。

大型系統架構設計

在設計大型系統的架構時，要特別注意對流量的控制，可以采取降級、限流和緩存等策略。在這里我們會給大家介紹一種常見的流量負載架構，然后再給出一個流行的軟件技術的選型。

服務預處理-限流與多層負載

為了保證億級流量下的高性能及高可用，除了精湛的編碼功底和巧妙的算法以外，還需要對海量請求進行多級限流和多層負載。在這里我們給大家介紹一種處理客戶端海量請求的思路，供讀者們參考，具體如下。

• 攔截非法請求，從而進行一定程度的限流，舉例如下。

• 加入驗證碼，防止機器人惡意攻擊。

• 隱藏秒殺入口地址，確保用戶在進行了合理的操作后才能進入。

• 限制 IP 操作：對于秒殺等限量業務，限制某一 IP 能夠發起請求的次數。

• 延長用戶操作時間：為避免用戶刷單，可以對具體業務在操作時間上進行限制，如同一用戶 5 秒鐘內只能進行一次操作。

• 通過 lvs 對客戶請求進行分流（負載均衡），并通過 keepalived 實現多機部署、防止單點故障。

• 通過 Nginx 將請求進行動靜分離：將靜態請求部署到 CDN 上進行加速（或直接在 Nginx 中緩存），將動態請求發送給 MQ 進行流量削峰（當有大量請求時，為減輕服務端壓力，可以先在 MQ 中設置可接收的最大請求量；超過最大值的請求將被直接丟棄）。

• 可以將同一個服務多次部署到多個節點上，形成集群服務（例如圖中有兩個“服務 A”），并用 Nginx 進行整合，用來實現并發請求的負載均衡和失敗遷移。

• 項目中的所有服務可以通過 Maven 或 Gradle 進行依賴管理，并使用 Git/GitHub 進行版本控制和團隊協作開發。

我們接下來要做的事情是進一步擴容，以上架構已經能夠扛得住千萬級的流量了，但如果遇到“雙十一購物”、“12306 搶票”、“大型電商秒殺”等億級流量，還需要做進一步改進。可以進行以下兩點擴充，搭建最終的 Lvs+Nginx+DNS 負載架構：

• 通過 DNS 綁定多個 LVS 組成的集群，進一步負載均衡。

• 通過 Nginx 對動態請求的路徑轉發到特定的服務地址上。例如，當用戶訪問 lanqiao.org/payment/時，Nginx 將該請求分發到服務 A 上，當用戶訪問 lanqiao.org/goods/時，Nginx 將該請求分發到服務 B 上。

值得注意的是，如果系統本身不是很大，那么是沒有必要使用以上所有組件的。例如軟負載均衡 LVS 的確可以減輕后面單個組件的壓力，但 LVS 自身也存在著不足：LVS 會使原本直接到達 Nginx 的請求在 LVS 自身中轉了一次，因此會增加系統中的網絡流量，并且帶來一定的延遲。簡言之，任何一個中間件都可能會增加系統的穩定性及性能，但同時也會存在著一定的弊端，在實際使用時一定要結合項目的實際情況慎重權衡。

后面會針對這樣的架構模型給大家引進復雜的大型系統采用分布式或者微服務架構是如何搭建具體的應用服務的，針對高并發系統和大型互聯網架構的介紹就是這些，大家多體會一下解決問題時層層遞進的方案是如何提出來的。

總結

高并發是每個大型項目和公司實際開發過程中都無法回避的一個問題，我們通過給大家高并發需求的業務場景，帶大家初始并了解了實際業務中并發性能提升對于整個系統的重要性。并通過如何設計一個大型系統方案全局掌控，給大家分析了設計原則并給出了一個實際的架構案例供大家學習，希望大家下來多琢磨，多研究和回顧。

同時為大家還整理總結了幾十個實戰項目，感興趣的同學可以在評論區留言或者私信我獲得更多資料。

總結

以上是生活随笔為你收集整理的「万字干货」高并发系统分析与大型互联网架构介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。