前言

?

高并發(fā)經(jīng)常會發(fā)生在有大活躍用戶量，用戶高聚集的業(yè)務場景中，如：秒殺活動，定時領(lǐng)取紅包等。

?

為了讓業(yè)務可以流暢的運行并且給用戶一個好的交互體驗，我們需要根據(jù)業(yè)務場景預估達到的并發(fā)量等因素，來設(shè)計適合自己業(yè)務場景的高并發(fā)處理方案。

?

在電商相關(guān)產(chǎn)品開發(fā)的這些年，我有幸的遇到了并發(fā)下的各種坑，這一路摸爬滾打過來有著不少的血淚史，這里進行的總結(jié)，作為自己的歸檔記錄，同時分享給大家。

?

服務器架構(gòu)

?

業(yè)務從發(fā)展的初期到逐漸成熟，服務器架構(gòu)也是從相對單一到集群，再到分布式服務。?

?

一個可以支持高并發(fā)的服務少不了好的服務器架構(gòu)，需要有均衡負載，數(shù)據(jù)庫需要主從集群，nosql緩存需要主從集群，靜態(tài)文件需要上傳cdn，這些都是能讓業(yè)務程序流暢運行的強大后盾。

?

服務器這塊多是需要運維人員來配合搭建，具體我就不多說了，點到為止。

?

大致需要用到的服務器架構(gòu)如下：

?

• 服務器

  • 均衡負載(如：nginx，阿里云SLB)

  • 資源監(jiān)控

  • 分布式

• 數(shù)據(jù)庫

  • 主從分離，集群

  • DBA 表優(yōu)化，索引優(yōu)化，等

  • 分布式

• nosql

  • 主從分離，集群

  • 主從分離，集群

  • 主從分離，集群

  • redis

  • mongodb

  • memcache

• cdn

  • html

  • css

  • js

  • image

?

并發(fā)測試

?

高并發(fā)相關(guān)的業(yè)務，需要進行并發(fā)的測試，通過大量的數(shù)據(jù)分析評估出整個架構(gòu)可以支撐的并發(fā)量。

?

測試高并發(fā)可以使用第三方服務器或者自己測試服務器，利用測試工具進行并發(fā)請求測試，分析測試數(shù)據(jù)得到可以支撐并發(fā)數(shù)量的評估，這個可以作為一個預警參考，俗話說知己自彼百戰(zhàn)不殆。

?

第三方服務：

?

• 阿里云性能測試

?

并發(fā)測試工具：

?

• Apache JMeter

• Visual Studio性能負載測試

• Microsoft Web Application Stress Tool

?

實戰(zhàn)方案

?

通用方案

?

日用戶流量大，但是比較分散，偶爾會有用戶高聚的情況；

?

場景： 用戶簽到，用戶中心，用戶訂單，等

?

服務器架構(gòu)圖：

說明：

?

場景中的這些業(yè)務基本是用戶進入APP后會操作到的，除了活動日(618,雙11，等)，這些業(yè)務的用戶量都不會高聚集，同時這些業(yè)務相關(guān)的表都是大數(shù)據(jù)表，業(yè)務多是查詢操作，所以我們需要減少用戶直接命中DB的查詢；優(yōu)先查詢緩存，如果緩存不存在，再進行DB查詢，將查詢結(jié)果緩存起來。

?

更新用戶相關(guān)緩存需要分布式存儲，比如使用用戶ID進行hash分組，把用戶分布到不同的緩存中，這樣一個緩存集合的總量不會很大，不會影響查詢效率。

?

方案如：

?

• 用戶簽到獲取積分

  • 計算出用戶分布的key,redis hash中查找用戶今日簽到信息

  • 如果查詢到簽到信息，返回簽到信息

  • 如果沒有查詢到，DB查詢今日是否簽到過，如果有簽到過，就把簽到信息同步redis緩存。

  • 如果DB中也沒有查詢到今日的簽到記錄，就進行簽到邏輯，操作DB添加今日簽到記錄，添加簽到積分(這整個DB操作是一個事務)

  • 緩存簽到信息到redis，返回簽到信息

  • 注意這里會有并發(fā)情況下的邏輯問題，如：一天簽到多次，發(fā)放多次積分給用戶。

  • 我的博文《大話程序猿眼里的高并發(fā)》（http://blog.thankbabe.com/2016/04/01/high-concurrency/）有相關(guān)的處理方案。

?

用戶訂單

• 這里我們只緩存用戶第一頁的訂單信息，一頁40條數(shù)據(jù)，用戶一般也只會看第一頁的訂單數(shù)據(jù)

• 用戶訪問訂單列表，如果是第一頁讀緩存，如果不是讀DB

• 計算出用戶分布的key,redis hash中查找用戶訂單信息

• 如果查詢到用戶訂單信息，返回訂單信息

• 如果不存在就進行DB查詢第一頁的訂單數(shù)據(jù)，然后緩存redis，返回訂單信息

?

用戶中心

• 計算出用戶分布的key,redis hash中查找用戶訂單信息

• 如果查詢到用戶信息，返回用戶信息

• 如果不存在進行用戶DB查詢，然后緩存redis，返回用戶信息

?

其他業(yè)務

• 上面例子多是針對用戶存儲緩存，如果是公用的緩存數(shù)據(jù)需要注意一些問題，如下

• 注意公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導致大量命中DB查詢，可以使用管理后臺更新緩存，或者DB查詢的鎖住操作。

• 我的博文《大話Redis進階》（http://blog.thankbabe.com/2016/08/05/redis-up/）對更新緩存問題和推薦方案的分享。

?

以上例子是一個相對簡單的高并發(fā)架構(gòu)，并發(fā)量不是很高的情況可以很好的支撐，但是隨著業(yè)務的壯大，用戶并發(fā)量增加，我們的架構(gòu)也會進行不斷的優(yōu)化和演變，比如對業(yè)務進行服務化，每個服務有自己的并發(fā)架構(gòu)，自己的均衡服務器，分布式數(shù)據(jù)庫，nosql主從集群，如：用戶服務、訂單服務；

?

消息隊列

?

秒殺、秒搶等活動業(yè)務，用戶在瞬間涌入產(chǎn)生高并發(fā)請求

?

場景：定時領(lǐng)取紅包，等

?

服務器架構(gòu)圖：

說明：

?

場景中的定時領(lǐng)取是一個高并發(fā)的業(yè)務，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊，hold不住就會宕機，然后影響整個業(yè)務；

?

像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數(shù)據(jù)的業(yè)務，前面提到的通用方案就無法支撐，并發(fā)的時候都是直接命中DB；

?

設(shè)計這塊業(yè)務的時候就會使用消息隊列的，可以將參與用戶的信息添加到消息隊列中，然后再寫個多線程程序去消耗隊列，給隊列中的用戶發(fā)放紅包；

?

方案如：

?

• 定時領(lǐng)取紅包

  • 一般習慣使用 redis的 list

  • 當用戶參與活動，將用戶參與信息push到隊列中

  • 然后寫個多線程程序去pop數(shù)據(jù)，進行發(fā)放紅包的業(yè)務

  • 這樣可以支持高并發(fā)下的用戶可以正常的參與活動，并且避免數(shù)據(jù)庫服務器宕機的危險

?

附加：?

?

通過消息隊列可以做很多的服務。?

?

如：定時短信發(fā)送服務，使用sset(sorted set)，發(fā)送時間戳作為排序依據(jù)，短信數(shù)據(jù)隊列根據(jù)時間升序，然后寫個程序定時循環(huán)去讀取sset隊列中的第一條，當前時間是否超過發(fā)送時間，如果超過就進行短信發(fā)送。

?

一級緩存

?

高并發(fā)請求連接緩存服務器超出服務器能夠接收的請求連接量，部分用戶出現(xiàn)建立連接超時無法讀取到數(shù)據(jù)的問題；

?

因此需要有個方案當高并發(fā)時候時候可以減少命中緩存服務器；

?

這時候就出現(xiàn)了一級緩存的方案，一級緩存就是使用站點服務器緩存去存儲數(shù)據(jù)，注意只存儲部分請求量大的數(shù)據(jù)，并且緩存的數(shù)據(jù)量要控制，不能過分的使用站點服務器的內(nèi)存而影響了站點應用程序的正常運行，一級緩存需要設(shè)置秒單位的過期時間，具體時間根據(jù)業(yè)務場景設(shè)定，目的是當有高并發(fā)請求的時候可以讓數(shù)據(jù)的獲取命中到一級緩存，而不用連接緩存nosql數(shù)據(jù)服務器，減少nosql數(shù)據(jù)服務器的壓力

?

比如APP首屏商品數(shù)據(jù)接口，這些數(shù)據(jù)是公共的不會針對用戶自定義，而且這些數(shù)據(jù)不會頻繁的更新，像這種接口的請求量比較大就可以加入一級緩存；

?

服務器架構(gòu)圖：

?

合理的規(guī)范和使用nosql緩存數(shù)據(jù)庫，根據(jù)業(yè)務拆分緩存數(shù)據(jù)庫的集群，這樣基本可以很好支持業(yè)務，一級緩存畢竟是使用站點服務器緩存所以還是要善用。

?

靜態(tài)化數(shù)據(jù)

?

高并發(fā)請求數(shù)據(jù)不變化的情況下如果可以不請求自己的服務器獲取數(shù)據(jù)那就可以減少服務器的資源壓力。

?

對于更新頻繁度不高，并且數(shù)據(jù)允許短時間內(nèi)的延遲，可以通過數(shù)據(jù)靜態(tài)化成JSON，XML,HTML等數(shù)據(jù)文件上傳CDN，在拉取數(shù)據(jù)的時候優(yōu)先到CDN拉取，如果沒有獲取到數(shù)據(jù)再從緩存，數(shù)據(jù)庫中獲取，當管理人員操作后臺編輯數(shù)據(jù)再重新生成靜態(tài)文件上傳同步到CDN，這樣在高并發(fā)的時候可以使數(shù)據(jù)的獲取命中在CDN服務器上。

?

CDN節(jié)點同步有一定的延遲性，所以找一個靠譜的CDN服務器商也很重要

?

其他方案

?

• 對于更新頻繁度不高的數(shù)據(jù)，APP,PC瀏覽器，可以緩存數(shù)據(jù)到本地，然后每次請求接口的時候上傳當前緩存數(shù)據(jù)的版本號，服務端接收到版本號判斷版本號與最新數(shù)據(jù)版本號是否一致，如果不一樣就進行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號，如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新。減少服務器壓力：資源、帶寬

?

針對上面的技術(shù)我特意整理了一下，有很多技術(shù)不是靠幾句話能講清楚，所以干脆找朋友錄制了一些視頻，很多問題其實答案很簡單，但是背后的思考和邏輯不簡單，要做到知其然還要知其所以然。如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我微信進群：emprere，群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家。

?

分層，分割，分布式

?

大型網(wǎng)站要很好支撐高并發(fā)，這是需要長期的規(guī)劃設(shè)計?

?

在初期就需要把系統(tǒng)進行分層，在發(fā)展過程中把核心業(yè)務進行拆分成模塊單元，根據(jù)需求進行分布式部署，可以進行獨立團隊維護開發(fā)。

?

• 分層

  • 將系統(tǒng)在橫向維度上切分成幾個部分，每個部門負責一部分相對簡單并比較單一的職責，然后通過上層對下層的依賴和調(diào)度組成一個完整的系統(tǒng)

  • 比如把電商系統(tǒng)分成：應用層，服務層，數(shù)據(jù)層。(具體分多少個層次根據(jù)自己的業(yè)務場景)

  • 應用層：網(wǎng)站首頁，用戶中心，商品中心，購物車，紅包業(yè)務，活動中心等，負責具體業(yè)務和視圖展示

  • 服務層：訂單服務，用戶管理服務，紅包服務，商品服務等，為應用層提供服務支持

  • 數(shù)據(jù)層：關(guān)系數(shù)據(jù)庫，nosql數(shù)據(jù)庫 等，提供數(shù)據(jù)存儲查詢服務

  • 分層架構(gòu)是邏輯上的，在物理部署上可以部署在同一臺物理機器上，但是隨著網(wǎng)站業(yè)務的發(fā)展，必然需要對已經(jīng)分層的模塊分離部署，分別部署在不同的服務器上，使網(wǎng)站可以支撐更多用戶訪問

?

分割

• 在縱向方面對業(yè)務進行切分，將一塊相對復雜的業(yè)務分割成不同的模塊單元

• 包裝成高內(nèi)聚低耦合的模塊不僅有助于軟件的開發(fā)維護，也便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴展

• 比如用戶中心可以分割成：賬戶信息模塊，訂單模塊，充值模塊，提現(xiàn)模塊，優(yōu)惠券模塊等

?

分布式

• 分布式應用和服務,將分層或者分割后的業(yè)務分布式部署，獨立的應用服務器，數(shù)據(jù)庫，緩存服務器

• 當業(yè)務達到一定用戶量的時候，再進行服務器均衡負載，數(shù)據(jù)庫，緩存主從集群

• 分布式靜態(tài)資源，比如：靜態(tài)資源上傳cdn

• 分布式計算，比如：使用hadoop進行大數(shù)據(jù)的分布式計算

• 分布式數(shù)據(jù)和存儲,比如：各分布節(jié)點根據(jù)哈希算法或其他算法分散存儲數(shù)據(jù)

?

?

網(wǎng)站分層-圖1來自網(wǎng)絡

?

集群

?

對于用戶訪問集中的業(yè)務獨立部署服務器，應用服務器，數(shù)據(jù)庫，nosql數(shù)據(jù)庫。 核心業(yè)務基本上需要搭建集群，即多臺服務器部署相同的應用構(gòu)成一個集群，通過負載均衡設(shè)備共同對外提供服務， 服務器集群能夠為相同的服務提供更多的并發(fā)支持，因此當有更多的用戶訪問時，只需要向集群中加入新的機器即可, 另外可以實現(xiàn)當其中的某臺服務器發(fā)生故障時，可以通過負載均衡的失效轉(zhuǎn)移機制將請求轉(zhuǎn)移至集群中其他的服務器上，因此可以提高系統(tǒng)的可用性

?

• 應用服務器集群

  • nginx 反向代理

  • slb

  • … …

• (關(guān)系/nosql)數(shù)據(jù)庫集群

  • 主從分離，從庫集群

?

?

通過反向代理均衡負載-圖2來自網(wǎng)絡

?

異步

?

在高并發(fā)業(yè)務中如果涉及到數(shù)據(jù)庫操作，主要壓力都是在數(shù)據(jù)庫服務器上面，雖然使用主從分離，但是數(shù)據(jù)庫操作都是在主庫上操作，單臺數(shù)據(jù)庫服務器連接池允許的最大連接數(shù)量是有限的?

?

當連接數(shù)量達到最大值的時候，其他需要連接數(shù)據(jù)操作的請求就需要等待有空閑的連接，這樣高并發(fā)的時候很多請求就會出現(xiàn)connection time out?的情況?

?

那么像這種高并發(fā)業(yè)務我們要如何設(shè)計開發(fā)方案可以降低數(shù)據(jù)庫服務器的壓力呢？

?

• 如：

  • 自動彈窗簽到，雙11跨0點的時候并發(fā)請求簽到接口

  • 雙11搶紅包活動

  • 雙11訂單入庫

  • 等

?

設(shè)計考慮：

• 逆向思維，壓力在數(shù)據(jù)庫，那業(yè)務接口就不進行數(shù)據(jù)庫操作不就沒壓力了

• 數(shù)據(jù)持久化是否允許延遲？

• 如何讓業(yè)務接口不直接操作DB，又可以讓數(shù)據(jù)持久化？

?

方案設(shè)計：

• 像這種涉及數(shù)據(jù)庫操作的高并發(fā)的業(yè)務，就要考慮使用異步了

• 客戶端發(fā)起接口請求，服務端快速響應，客戶端展示結(jié)果給用戶，數(shù)據(jù)庫操作通過異步同步

• 如何實現(xiàn)異步同步？

• 使用消息隊列，將入庫的內(nèi)容enqueue到消息隊列中，業(yè)務接口快速響應給用戶結(jié)果(可以溫馨提示高峰期延遲到賬)

• 然后再寫個獨立程序從消息隊列dequeue數(shù)據(jù)出來進行入庫操作，入庫成功后刷新用戶相關(guān)緩存，如果入庫失敗記錄日志，方便反饋查詢和重新持久化

• 這樣一來數(shù)據(jù)庫操作就只有一個程序(多線程)來完成，不會給數(shù)據(jù)帶來壓力

?

補充：

• 消息隊列除了可以用在高并發(fā)業(yè)務，其他只要有相同需求的業(yè)務也是可以使用，如：短信發(fā)送中間件等

• 高并發(fā)下異步持久化數(shù)據(jù)可能會影響用戶的體驗，可以通過可配置的方式，或者自動化監(jiān)控資源消耗來切換時時或者使用異步，這樣在正常流量的情況下可以使用時時操作數(shù)據(jù)庫來提高用戶體驗

• 異步同時也可以指編程上的異步函數(shù)，異步線程，在有的時候可以使用異步操作，把不需要等待結(jié)果的操作放到異步中，然后繼續(xù)后面的操作，節(jié)省了等待的這部分操作的時間

?

緩存

?

高并發(fā)業(yè)務接口多數(shù)都是進行業(yè)務數(shù)據(jù)的查詢，如：商品列表，商品信息，用戶信息，紅包信息等，這些數(shù)據(jù)都是不會經(jīng)常變化，并且持久化在數(shù)據(jù)庫中

?

高并發(fā)的情況下直接連接從庫做查詢操作，多臺從庫服務器也抗不住這么大量的連接請求數(shù)（前面說過，單臺數(shù)據(jù)庫服務器允許的最大連接數(shù)量是有限的）

?

那么我們在這種高并發(fā)的業(yè)務接口要如何設(shè)計呢？

?

• 設(shè)計考慮：

  • 還是逆向思維，壓力在數(shù)據(jù)庫，那么我們就不進行數(shù)據(jù)庫查詢

  • 數(shù)據(jù)不經(jīng)常變化，我們?yōu)樯兑恢辈樵僁B？

  • 數(shù)據(jù)不變化客戶端為啥要向服務器請求返回一樣的數(shù)據(jù)？

?

方案設(shè)計：

• 數(shù)據(jù)不經(jīng)常變化，我們可以把數(shù)據(jù)進行緩存，緩存的方式有很多種，一般的：應用服務器直接Cache內(nèi)存，主流的：存儲在memcache、redis內(nèi)存數(shù)據(jù)庫

• Cache是直接存儲在應用服務器中，讀取速度快，內(nèi)存數(shù)據(jù)庫服務器允許連接數(shù)可以支撐到很大，而且數(shù)據(jù)存儲在內(nèi)存，讀取速度快，再加上主從集群，可以支撐很大的并發(fā)查詢

• 根據(jù)業(yè)務情景，使用配合客戶端本地存，如果我們數(shù)據(jù)內(nèi)容不經(jīng)常變化，為啥要一直請求服務器獲取相同數(shù)據(jù)，可以通過匹配數(shù)據(jù)版本號，如果版本號不一樣接口重新查詢緩存返回數(shù)據(jù)和版本號，如果一樣則不查詢數(shù)據(jù)直接響應

• 這樣不僅可以提高接口響應速度，也可以節(jié)約服務器帶寬，雖然有些服務器帶寬是按流量計費，但是也不是絕對無限的，在高并發(fā)的時候服務器帶寬也可能導致請求響應慢的問題

?

補充：

• 緩存同時也指靜態(tài)資源客戶端緩存

• cdn緩存，靜態(tài)資源通過上傳cdn，cdn節(jié)點緩存我們的靜態(tài)資源，減少服務器壓力

?

面向服務

?

• SOA面向服務架構(gòu)設(shè)計

• 微服務更細粒度服務化，一系列的獨立的服務共同組成系統(tǒng)

?

使用服務化思維，將核心業(yè)務或者通用的業(yè)務功能抽離成服務獨立部署，對外提供接口的方式提供功能。

?

最理想化的設(shè)計是可以把一個復雜的系統(tǒng)抽離成多個服務，共同組成系統(tǒng)的業(yè)務，優(yōu)點：松耦合，高可用性，高伸縮性，易維護。

?

通過面向服務化設(shè)計，獨立服務器部署，均衡負載，數(shù)據(jù)庫集群，可以讓服務支撐更高的并發(fā)

?

• 服務例子：

  • 用戶行為跟蹤記錄統(tǒng)計

?

說明：

• 通過上報應用模塊，操作事件，事件對象，等數(shù)據(jù)，記錄用戶的操作行為

• 比如：記錄用戶在某個商品模塊，點擊了某一件商品，或者瀏覽了某一件商品

?

背景：

• 由于服務需要記錄用戶的各種操作行為，并且可以重復上報，準備接入服務的業(yè)務又是核心業(yè)務的用戶行為跟蹤，所以請求量很大，高峰期會產(chǎn)生大量并發(fā)請求。

  ?

架構(gòu)：

• nodejs WEB應用服務器均衡負載

• redis主從集群

• mysql主

• nodejs+express+ejs+redis+mysql

• 服務端采用nodejs,nodejs是單進程（PM2根據(jù)cpu核數(shù)開啟多個工作進程），采用事件驅(qū)動機制，適合I/O密集型業(yè)務，處理高并發(fā)能力強

  ?

業(yè)務設(shè)計：

• 并發(fā)量大，所以不能直接入庫，采用：異步同步數(shù)據(jù),消息隊列

• 請求接口上報數(shù)據(jù)，接口將上報數(shù)據(jù)push到redis的list隊列中

• nodejs寫入庫腳本，循環(huán)pop redis list數(shù)據(jù)，將數(shù)據(jù)存儲入庫，并進行相關(guān)統(tǒng)計Update，無數(shù)據(jù)時sleep幾秒

• 因為數(shù)據(jù)量會比較大，上報的數(shù)據(jù)表按天命名存儲

  ?

接口：

• 上報數(shù)據(jù)接口

• 統(tǒng)計查詢接口

?

上線跟進：

• 服務業(yè)務基本正常

• 每天的上報表有上千萬的數(shù)據(jù)

?

冗余，自動化

?

當高并發(fā)業(yè)務所在的服務器出現(xiàn)宕機的時候，需要有備用服務器進行快速的替代，在應用服務器壓力大的時候可以快速添加機器到集群中，所以我們就需要有備用機器可以隨時待命。 最理想的方式是可以通過自動化監(jiān)控服務器資源消耗來進行報警，自動切換降級方案，自動的進行服務器替換和添加操作等，通過自動化可以減少人工的操作的成本，而且可以快速操作，避免人為操作上面的失誤。

?

• 冗余

  • 數(shù)據(jù)庫備份

  • 備用服務器

• 自動化

  • 自動化監(jiān)控

  • 自動化報警

  • 自動化降級

?

通過GitLab事件，我們應該反思，做了備份數(shù)據(jù)并不代表就萬無一失了，我們需要保證高可用性，首先備份是否正常進行，備份數(shù)據(jù)是否可用，需要我們進行定期的檢查，或者自動化監(jiān)控， 還有包括如何避免人為上的操作失誤問題。(不過事件中g(shù)itlab的開放性姿態(tài)，積極的處理方式還是值得學習的)

?

總結(jié)

?

高并發(fā)架構(gòu)是一個不斷衍變的過程，冰洞三尺非一日之寒，長城筑成非一日之功 。

?

打好基礎(chǔ)架構(gòu)方便以后的拓展，這點很重要。

總結(jié)

以上是生活随笔為你收集整理的java架构师眼中的高并发架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。