來源:http://mp.weixin.qq.com/s?__biz=MzI4OTU3ODk3NQ==&mid=2247483793&idx=1&sn=b91f162a2428c47f29d5723c689a20ba&chksm=ec2c4b21db5bc2379b91f39875b52832ac451a331070e014499ce996c9db610d8414951f61dc&mpshare=1&scene=23&srcid=0109Y54puxgjtDAiZQ98oVMG#rd

前言

高并發經常會發生在有大活躍用戶量，用戶高聚集的業務場景中，如：秒殺活動，定時領取紅包等。

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

服務器架構

業務從發展的初期到逐漸成熟，服務器架構也是從相對單一到集群，再到分布式服務。

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

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

大致需要用到的服務器架構如下：

• 服務器

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

資源監控

分布式

• 數據庫

主從分離，集群

DBA 表優化，索引優化，等

分布式

• nosql

redis
主從分離，集群

mongodb
主從分離，集群

memcache
主從分離，集群

• cdn

html

css

js

image

并發測試

高并發相關的業務，需要進行并發的測試，通過大量的數據分析評估出整個架構可以支撐的并發量。

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

第三方服務:

• 阿里云性能測試

并發測試工具：

• Apache JMeter

• Visual Studio性能負載測試

• Microsoft Web Application Stress Tool

實戰方案

通用方案

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

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

服務器架構圖：

說明：

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

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

方案如：

• 用戶簽到獲取積分

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

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

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

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

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

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

• 用戶訂單

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

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

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

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

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

• 用戶中心

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

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

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

• 其他業務

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

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

我的博文[大話Redis進階]對更新緩存問題和推薦方案的分享。

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

消息隊列

秒殺、秒搶等活動業務，用戶在瞬間涌入產生高并發請求
場景：定時領取紅包，等

服務器架構圖：

說明：

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

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

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

方案如：

• 定時領取紅包

一般習慣使用 redis的 list

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

然后寫個多線程程序去pop數據，進行發放紅包的業務

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

附加：

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

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

一級緩存

高并發請求連接緩存服務器，超出服務器能夠接收的請求連接量，部分用戶出現建立連接超時無法讀取到數據的問題；

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

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

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

服務器架構圖：

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

靜態化數據

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

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

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

其他方案

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

總結

以上是生活随笔為你收集整理的程序猿眼里的高并发架构的全部內容，希望文章能夠幫你解決所遇到的問題。

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