這篇文章運(yùn)用簡單易懂的例子給大家介紹什么是Java高并發(fā)架構(gòu)設(shè)計(jì)，代碼非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

創(chuàng)新互聯(lián)成立與2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都外貿(mào)網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元上黨做網(wǎng)站,已為上家服務(wù),為上黨各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

序言

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

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

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

一丶服務(wù)器架構(gòu)

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

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

服務(wù)器這塊多是需要運(yùn)維人員來配合搭建，具體我就不多說了，點(diǎn)到為止。

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

服務(wù)器

均衡負(fù)載(如：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è)務(wù)，需要進(jìn)行并發(fā)的測試，通過大量的數(shù)據(jù)分析評(píng)估出整個(gè)架構(gòu)可以支撐的并發(fā)量。

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

第三方服務(wù):

阿里云性能測試

并發(fā)測試工具：

Apache JMeter

Visual Studio性能負(fù)載測試

Microsoft Web Application Stress Tool

實(shí)戰(zhàn)方案

通用方案

日用戶流量大，但是比較分散，偶爾會(huì)有用戶高聚的情況;

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

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

說明：

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

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

方案如：

用戶簽到獲取積分

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

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

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

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

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

注意

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

我的博文[大話程序猿眼里的高并發(fā)]有相關(guān)的處理方案。

用戶訂單

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

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

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

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

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

用戶中心

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

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

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

其他業(yè)務(wù)

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

消息隊(duì)列

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

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

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

說明：

場景中的定時(shí)領(lǐng)取是一個(gè)高并發(fā)的業(yè)務(wù)，像秒殺活動(dòng)用戶會(huì)在到點(diǎn)的時(shí)間涌入，DB瞬間就接受到一記暴擊，hold不住就會(huì)宕機(jī)，然后影響整個(gè)業(yè)務(wù);

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

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

方案如：

定時(shí)領(lǐng)取紅包

一般習(xí)慣使用 redis的 list

當(dāng)用戶參與活動(dòng)，將用戶參與信息push到隊(duì)列中

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

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

一級(jí)緩存

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

因此需要有個(gè)方案當(dāng)高并發(fā)時(shí)候時(shí)候可以減少命中緩存服務(wù)器;

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

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

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

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

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

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

對(duì)于更新頻繁度不高，并且數(shù)據(jù)允許短時(shí)間內(nèi)的延遲，可以通過數(shù)據(jù)靜態(tài)化成JSON，XML,HTML等數(shù)據(jù)文件上傳CDN，在拉取數(shù)據(jù)的時(shí)候優(yōu)先到CDN拉取，如果沒有獲取到數(shù)據(jù)再從緩存，數(shù)據(jù)庫中獲取，當(dāng)管理人員操作后臺(tái)編輯數(shù)據(jù)再重新生成靜態(tài)文件上傳同步到CDN，這樣在高并發(fā)的時(shí)候可以使數(shù)據(jù)的獲取命中在CDN服務(wù)器上。CDN節(jié)點(diǎn)同步有一定的延遲性，所以找一個(gè)靠譜的CDN服務(wù)器商也很重要。

關(guān)于什么是Java高并發(fā)架構(gòu)設(shè)計(jì)就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。