您好,登錄后才能下訂單哦!
這篇文章將為大家詳細(xì)講解有關(guān)web中高并發(fā)架構(gòu)的示例分析,小編覺(jué)得挺實(shí)用的,因此分享給大家做個(gè)參考,希望大家閱讀完這篇文章后可以有所收獲。
服務(wù)器架構(gòu)
業(yè)務(wù)從發(fā)展的初期到逐漸成熟,服務(wù)器架構(gòu)也是從相對(duì)單一到集群,再到分布式服務(wù)。
一個(gè)可以支持高并發(fā)的服務(wù)少不了好的服務(wù)器架構(gòu),需要有均衡負(fù)載,數(shù)據(jù)庫(kù)需要主從集群,nosql緩存需要主從集群,靜態(tài)文件需要上傳cdn,這些都是能讓業(yè)務(wù)程序流暢運(yùn)行的強(qiáng)大后盾。
服務(wù)器這塊多是需要運(yùn)維人員來(lái)配合搭建,具體我就不多說(shuō)了,點(diǎn)到為止。
大致需要用到的服務(wù)器架構(gòu)如下:
服務(wù)器
均衡負(fù)載(如:nginx,阿里云SLB)
資源監(jiān)控
分布式
數(shù)據(jù)庫(kù)
主從分離,集群
DBA 表優(yōu)化,索引優(yōu)化,等
分布式
nosql
主從分離,集群
memcache
cdn
html
css
js
image
并發(fā)測(cè)試
高并發(fā)相關(guān)的業(yè)務(wù),需要進(jìn)行并發(fā)的測(cè)試,通過(guò)大量的數(shù)據(jù)分析評(píng)估出整個(gè)架構(gòu)可以支撐的并發(fā)量。
測(cè)試高并發(fā)可以使用第三方服務(wù)器或者自己測(cè)試服務(wù)器,利用測(cè)試工具進(jìn)行并發(fā)請(qǐng)求測(cè)試,分析測(cè)試數(shù)據(jù)得到可以支撐并發(fā)數(shù)量的評(píng)估,這個(gè)可以作為一個(gè)預(yù)警參考,俗話說(shuō)知己自彼百戰(zhàn)不殆。
第三方服務(wù):
阿里云性能測(cè)試
并發(fā)測(cè)試工具:
Apache JMeter
Visual Studio性能負(fù)載測(cè)試
Microsoft Web Application Stress Tool
實(shí)戰(zhàn)方案
通用方案
日用戶流量大,但是比較分散,偶爾會(huì)有用戶高聚的情況;
場(chǎng)景: 用戶簽到,用戶中心,用戶訂單,等
服務(wù)器架構(gòu)圖:
說(shuō)明:
場(chǎng)景中的這些業(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é)果緩存起來(lái)。
更新用戶相關(guān)緩存需要分布式存儲(chǔ),比如使用用戶ID進(jìn)行hash分組,把用戶分布到不同的緩存中,這樣一個(gè)緩存集合的總量不會(huì)很大,不會(huì)影響查詢效率。
方案如:
用戶簽到獲取積分
計(jì)算出用戶分布的key,redis hash中查找用戶今日簽到信息
如果查詢到簽到信息,返回簽到信息
如果沒(méi)有查詢到,DB查詢今日是否簽到過(guò),如果有簽到過(guò),就把簽到信息同步redis緩存。
如果DB中也沒(méi)有查詢到今日的簽到記錄,就進(jìn)行簽到邏輯,操作DB添加今日簽到記錄,添加簽到積分(這整個(gè)DB操作是一個(gè)事務(wù))
緩存簽到信息到redis,返回簽到信息
注意這里會(huì)有并發(fā)情況下的邏輯問(wèn)題,如:一天簽到多次,發(fā)放多次積分給用戶。
我的博文[大話程序猿眼里的高并發(fā)]有相關(guān)的處理方案。
用戶訂單
這里我們只緩存用戶第一頁(yè)的訂單信息,一頁(yè)40條數(shù)據(jù),用戶一般也只會(huì)看第一頁(yè)的訂單數(shù)據(jù)
用戶訪問(wèn)訂單列表,如果是第一頁(yè)讀緩存,如果不是讀DB
計(jì)算出用戶分布的key,redis hash中查找用戶訂單信息
如果查詢到用戶訂單信息,返回訂單信息
如果不存在就進(jìn)行DB查詢第一頁(yè)的訂單數(shù)據(jù),然后緩存redis,返回訂單信息
用戶中心
計(jì)算出用戶分布的key,redis hash中查找用戶訂單信息
如果查詢到用戶信息,返回用戶信息
如果不存在進(jìn)行用戶DB查詢,然后緩存redis,返回用戶信息
其他業(yè)務(wù)
上面例子多是針對(duì)用戶存儲(chǔ)緩存,如果是公用的緩存數(shù)據(jù)需要注意一些問(wèn)題,如下
注意公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會(huì)導(dǎo)致大量命中DB查詢,可以使用管理后臺(tái)更新緩存,或者DB查詢的鎖住操作。
我的博文[大話Redis進(jìn)階]對(duì)更新緩存問(wèn)題和推薦方案的分享。
以上例子是一個(gè)相對(duì)簡(jiǎn)單的高并發(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ù)庫(kù),nosql主從集群,如:用戶服務(wù)、訂單服務(wù);
消息隊(duì)列
秒殺、秒搶等活動(dòng)業(yè)務(wù),用戶在瞬間涌入產(chǎn)生高并發(fā)請(qǐng)求
場(chǎng)景:定時(shí)領(lǐng)取紅包,等
服務(wù)器架構(gòu)圖:
說(shuō)明:
場(chǎng)景中的定時(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ù),前面提到的通用方案就無(wú)法支撐,并發(fā)的時(shí)候都是直接命中DB;
設(shè)計(jì)這塊業(yè)務(wù)的時(shí)候就會(huì)使用消息隊(duì)列的,可以將參與用戶的信息添加到消息隊(duì)列中,然后再寫(xiě)個(gè)多線程程序去消耗隊(duì)列,給隊(duì)列中的用戶發(fā)放紅包;
方案如:
定時(shí)領(lǐng)取紅包
一般習(xí)慣使用 redis的 list
當(dāng)用戶參與活動(dòng),將用戶參與信息push到隊(duì)列中
然后寫(xiě)個(gè)多線程程序去pop數(shù)據(jù),進(jìn)行發(fā)放紅包的業(yè)務(wù)
這樣可以支持高并發(fā)下的用戶可以正常的參與活動(dòng),并且避免數(shù)據(jù)庫(kù)服務(wù)器宕機(jī)的危險(xiǎn)
附加:
通過(guò)消息隊(duì)列可以做很多的服務(wù)。
如:定時(shí)短信發(fā)送服務(wù),使用sset(sorted set),發(fā)送時(shí)間戳作為排序依據(jù),短信數(shù)據(jù)隊(duì)列根據(jù)時(shí)間升序,然后寫(xiě)個(gè)程序定時(shí)循環(huán)去讀取sset隊(duì)列中的第一條,當(dāng)前時(shí)間是否超過(guò)發(fā)送時(shí)間,如果超過(guò)就進(jìn)行短信發(fā)送。
一級(jí)緩存
高并發(fā)請(qǐng)求連接緩存服務(wù)器超出服務(wù)器能夠接收的請(qǐng)求連接量,部分用戶出現(xiàn)建立連接超時(shí)無(wú)法讀取到數(shù)據(jù)的問(wèn)題;
因此需要有個(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ù)量要控制,不能過(guò)分的使用站點(diǎn)服務(wù)器的內(nèi)存而影響了站點(diǎn)應(yīng)用程序的正常運(yùn)行,一級(jí)緩存需要設(shè)置秒單位的過(guò)期時(shí)間,具體時(shí)間根據(jù)業(yè)務(wù)場(chǎng)景設(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ù)庫(kù),根據(jù)業(yè)務(wù)拆分緩存數(shù)據(jù)庫(kù)的集群,這樣基本可以很好支持業(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)的延遲,可以通過(guò)數(shù)據(jù)靜態(tài)化成JSON,XML,HTML等數(shù)據(jù)文件上傳CDN,在拉取數(shù)據(jù)的時(shí)候優(yōu)先到CDN拉取,如果沒(méi)有獲取到數(shù)據(jù)再?gòu)木彺?,?shù)據(jù)庫(kù)中獲取,當(dāng)管理人員操作后臺(tái)編輯數(shù)據(jù)再重新生成靜態(tài)文件上傳同步到CDN,這樣在高并發(fā)的時(shí)候可以使數(shù)據(jù)的獲取命中在CDN服務(wù)器上。
CDN節(jié)點(diǎn)同步有一定的延遲性,所以找一個(gè)靠譜的CDN服務(wù)器商也很重要
針對(duì)上面的技術(shù)我特意整理了一下,有很多技術(shù)不是靠幾句話能講清楚,所以干脆找朋友錄制了一些視頻,很多問(wèn)題其實(shí)很簡(jiǎn)單,但是背后的思考和邏輯不簡(jiǎn)單,要做到知其然還要知其所以然。費(fèi)分享給大家。
其他方案
對(duì)于更新頻繁度不高的數(shù)據(jù),APP,PC瀏覽器,可以緩存數(shù)據(jù)到本地,然后每次請(qǐng)求接口的時(shí)候上傳當(dāng)前緩存數(shù)據(jù)的版本號(hào),服務(wù)端接收到版本號(hào)判斷版本號(hào)與最新數(shù)據(jù)版本號(hào)是否一致,如果不一樣就進(jìn)行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號(hào),如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新。
關(guān)于“web中高并發(fā)架構(gòu)的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,使各位可以學(xué)到更多知識(shí),如果覺(jué)得文章不錯(cuò),請(qǐng)把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。