本篇內(nèi)容主要講解“服務(wù)器的高并發(fā)架構(gòu)實(shí)例分析”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“服務(wù)器的高并發(fā)架構(gòu)實(shí)例分析”吧!
業(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
主從分離，集群
主從分離，集群
主從分離，集群
redis
mongodb
memcache
cdn
html
css
js
image
高并發(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
日用戶流量大，但是比較分散，偶爾會(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ā)放多次積分給用戶。
用戶訂單
這里我們只緩存用戶第一頁(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查詢的鎖住操作。
以上例子是一個(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ù)；
秒殺、秒搶等活動(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ì)列中，然后再寫個(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ù)庫(kù)服務(wù)器宕機(jī)的危險(xiǎn)
附加：
通過(guò)消息隊(duì)列可以做很多的服務(wù)。
如：定時(shí)短信發(fā)送服務(wù)，使用sset(sorted set)，發(fā)送時(shí)間戳作為排序依據(jù)，短信數(shù)據(jù)隊(duì)列根據(jù)時(shí)間升序，然后寫個(gè)程序定時(shí)循環(huán)去讀取sset隊(duì)列中的第一條，當(dāng)前時(shí)間是否超過(guò)發(fā)送時(shí)間，如果超過(guò)就進(jìn)行短信發(fā)送。
高并發(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ù)器緩存所以還是要善用。
高并發(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ù)據(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)是最新。減少服務(wù)器壓力：資源、帶寬等.
分層，分割，分布式
大型網(wǎng)站要很好支撐高并發(fā)，這是需要長(zhǎng)期的規(guī)劃設(shè)計(jì)
在初期就需要把系統(tǒng)進(jìn)行分層，在發(fā)展過(guò)程中把核心業(yè)務(wù)進(jìn)行拆分成模塊單元，根據(jù)需求進(jìn)行分布式部署，可以進(jìn)行獨(dú)立團(tuán)隊(duì)維護(hù)開(kāi)發(fā)。
分層
將系統(tǒng)在橫向維度上切分成幾個(gè)部分，每個(gè)部門負(fù)責(zé)一部分相對(duì)簡(jiǎn)單并比較單一的職責(zé)，然后通過(guò)上層對(duì)下層的依賴和調(diào)度組成一個(gè)完整的系統(tǒng)
比如把電商系統(tǒng)分成：應(yīng)用層，服務(wù)層，數(shù)據(jù)層。(具體分多少個(gè)層次根據(jù)自己的業(yè)務(wù)場(chǎng)景)
應(yīng)用層：網(wǎng)站首頁(yè)，用戶中心，商品中心，購(gòu)物車，紅包業(yè)務(wù)，活動(dòng)中心等，負(fù)責(zé)具體業(yè)務(wù)和視圖展示
服務(wù)層：訂單服務(wù)，用戶管理服務(wù)，紅包服務(wù)，商品服務(wù)等，為應(yīng)用層提供服務(wù)支持
數(shù)據(jù)層：關(guān)系數(shù)據(jù)庫(kù)，nosql數(shù)據(jù)庫(kù) 等，提供數(shù)據(jù)存儲(chǔ)查詢服務(wù)
分層架構(gòu)是邏輯上的，在物理部署上可以部署在同一臺(tái)物理機(jī)器上，但是隨著網(wǎng)站業(yè)務(wù)的發(fā)展，必然需要對(duì)已經(jīng)分層的模塊分離部署，分別部署在不同的服務(wù)器上，使網(wǎng)站可以支撐更多用戶訪問(wèn)
分割
在縱向方面對(duì)業(yè)務(wù)進(jìn)行切分，將一塊相對(duì)復(fù)雜的業(yè)務(wù)分割成不同的模塊單元
包裝成高內(nèi)聚低耦合的模塊不僅有助于軟件的開(kāi)發(fā)維護(hù)，也便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴(kuò)展
比如用戶中心可以分割成：賬戶信息模塊，訂單模塊，充值模塊，提現(xiàn)模塊，優(yōu)惠券模塊等
分布式
分布式應(yīng)用和服務(wù),將分層或者分割后的業(yè)務(wù)分布式部署，獨(dú)立的應(yīng)用服務(wù)器，數(shù)據(jù)庫(kù)，緩存服務(wù)器
當(dāng)業(yè)務(wù)達(dá)到一定用戶量的時(shí)候，再進(jìn)行服務(wù)器均衡負(fù)載，數(shù)據(jù)庫(kù)，緩存主從集群
分布式靜態(tài)資源，比如：靜態(tài)資源上傳cdn
分布式計(jì)算，比如：使用hadoop進(jìn)行大數(shù)據(jù)的分布式計(jì)算
分布式數(shù)據(jù)和存儲(chǔ),比如：各分布節(jié)點(diǎn)根據(jù)哈希算法或其他算法分散存儲(chǔ)數(shù)據(jù)
對(duì)于用戶訪問(wèn)集中的業(yè)務(wù)獨(dú)立部署服務(wù)器，應(yīng)用服務(wù)器，數(shù)據(jù)庫(kù)，nosql數(shù)據(jù)庫(kù)。 核心業(yè)務(wù)基本上需要搭建集群，即多臺(tái)服務(wù)器部署相同的應(yīng)用構(gòu)成一個(gè)集群，通過(guò)負(fù)載均衡設(shè)備共同對(duì)外提供服務(wù)， 服務(wù)器集群能夠?yàn)橄嗤姆?wù)提供更多的并發(fā)支持，因此當(dāng)有更多的用戶訪問(wèn)時(shí)，只需要向集群中加入新的機(jī)器即可, 另外可以實(shí)現(xiàn)當(dāng)其中的某臺(tái)服務(wù)器發(fā)生故障時(shí)，可以通過(guò)負(fù)載均衡的失效轉(zhuǎn)移機(jī)制將請(qǐng)求轉(zhuǎn)移至集群中其他的服務(wù)器上，因此可以提高系統(tǒng)的可用性
應(yīng)用服務(wù)器集群
nginx 反向代理
slb
… …
(關(guān)系/nosql)數(shù)據(jù)庫(kù)集群
主從分離，從庫(kù)集群
在高并發(fā)業(yè)務(wù)中如果涉及到數(shù)據(jù)庫(kù)操作，主要壓力都是在數(shù)據(jù)庫(kù)服務(wù)器上面，雖然使用主從分離，但是數(shù)據(jù)庫(kù)操作都是在主庫(kù)上操作，單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器連接池允許的大連接數(shù)量是有限的
當(dāng)連接數(shù)量達(dá)到大值的時(shí)候，其他需要連接數(shù)據(jù)操作的請(qǐng)求就需要等待有空閑的連接，這樣高并發(fā)的時(shí)候很多請(qǐng)求就會(huì)出現(xiàn)connection time out 的情況
那么像這種高并發(fā)業(yè)務(wù)我們要如何設(shè)計(jì)開(kāi)發(fā)方案可以降低數(shù)據(jù)庫(kù)服務(wù)器的壓力呢？
如：
自動(dòng)彈窗簽到，雙11跨0點(diǎn)的時(shí)候并發(fā)請(qǐng)求簽到接口
雙11搶紅包活動(dòng)
雙11訂單入庫(kù)
等
設(shè)計(jì)考慮：
逆向思維，壓力在數(shù)據(jù)庫(kù)，那業(yè)務(wù)接口就不進(jìn)行數(shù)據(jù)庫(kù)操作不就沒(méi)壓力了
數(shù)據(jù)持久化是否允許延遲？
如何讓業(yè)務(wù)接口不直接操作DB，又可以讓數(shù)據(jù)持久化？
方案設(shè)計(jì)：
像這種涉及數(shù)據(jù)庫(kù)操作的高并發(fā)的業(yè)務(wù)，就要考慮使用異步了
客戶端發(fā)起接口請(qǐng)求，服務(wù)端快速響應(yīng)，客戶端展示結(jié)果給用戶，數(shù)據(jù)庫(kù)操作通過(guò)異步同步
如何實(shí)現(xiàn)異步同步？
使用消息隊(duì)列，將入庫(kù)的內(nèi)容enqueue到消息隊(duì)列中，業(yè)務(wù)接口快速響應(yīng)給用戶結(jié)果(可以溫馨提示高峰期延遲到賬)
然后再寫個(gè)獨(dú)立程序從消息隊(duì)列dequeue數(shù)據(jù)出來(lái)進(jìn)行入庫(kù)操作，入庫(kù)成功后刷新用戶相關(guān)緩存，如果入庫(kù)失敗記錄日志，方便反饋查詢和重新持久化
這樣一來(lái)數(shù)據(jù)庫(kù)操作就只有一個(gè)程序(多線程)來(lái)完成，不會(huì)給數(shù)據(jù)帶來(lái)壓力
補(bǔ)充：
消息隊(duì)列除了可以用在高并發(fā)業(yè)務(wù)，其他只要有相同需求的業(yè)務(wù)也是可以使用，如：短信發(fā)送中間件等
高并發(fā)下異步持久化數(shù)據(jù)可能會(huì)影響用戶的體驗(yàn)，可以通過(guò)可配置的方式，或者自動(dòng)化監(jiān)控資源消耗來(lái)切換時(shí)時(shí)或者使用異步，這樣在正常流量的情況下可以使用時(shí)時(shí)操作數(shù)據(jù)庫(kù)來(lái)提高用戶體驗(yàn)
異步同時(shí)也可以指編程上的異步函數(shù)，異步線程，在有的時(shí)候可以使用異步操作，把不需要等待結(jié)果的操作放到異步中，然后繼續(xù)后面的操作，節(jié)省了等待的這部分操作的時(shí)間
緩存
高并發(fā)業(yè)務(wù)接口多數(shù)都是進(jìn)行業(yè)務(wù)數(shù)據(jù)的查詢，如：商品列表，商品信息，用戶信息，紅包信息等，這些數(shù)據(jù)都是不會(huì)經(jīng)常變化，并且持久化在數(shù)據(jù)庫(kù)中
高并發(fā)的情況下直接連接從庫(kù)做查詢操作，多臺(tái)從庫(kù)服務(wù)器也抗不住這么大量的連接請(qǐng)求數(shù)（前面說(shuō)過(guò)，單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器允許的大連接數(shù)量是有限的）
那么我們?cè)谶@種高并發(fā)的業(yè)務(wù)接口要如何設(shè)計(jì)呢？
設(shè)計(jì)考慮：
還是逆向思維，壓力在數(shù)據(jù)庫(kù)，那么我們就不進(jìn)行數(shù)據(jù)庫(kù)查詢
數(shù)據(jù)不經(jīng)常變化，我們?yōu)樯兑恢辈樵僁B？
數(shù)據(jù)不變化客戶端為啥要向服務(wù)器請(qǐng)求返回一樣的數(shù)據(jù)？
方案設(shè)計(jì)：
數(shù)據(jù)不經(jīng)常變化，我們可以把數(shù)據(jù)進(jìn)行緩存，緩存的方式有很多種，一般的：應(yīng)用服務(wù)器直接Cache內(nèi)存，主流的：存儲(chǔ)在memcache、redis內(nèi)存數(shù)據(jù)庫(kù)
Cache是直接存儲(chǔ)在應(yīng)用服務(wù)器中，讀取速度快，內(nèi)存數(shù)據(jù)庫(kù)服務(wù)器允許連接數(shù)可以支撐到很大，而且數(shù)據(jù)存儲(chǔ)在內(nèi)存，讀取速度快，再加上主從集群，可以支撐很大的并發(fā)查詢
根據(jù)業(yè)務(wù)情景，使用配合客戶端本地存，如果我們數(shù)據(jù)內(nèi)容不經(jīng)常變化，為啥要一直請(qǐng)求服務(wù)器獲取相同數(shù)據(jù)，可以通過(guò)匹配數(shù)據(jù)版本號(hào)，如果版本號(hào)不一樣接口重新查詢緩存返回?cái)?shù)據(jù)和版本號(hào)，如果一樣則不查詢數(shù)據(jù)直接響應(yīng)
這樣不僅可以提高接口響應(yīng)速度，也可以節(jié)約服務(wù)器帶寬，雖然有些服務(wù)器帶寬是按流量計(jì)費(fèi)，但是也不是絕對(duì)無(wú)限的，在高并發(fā)的時(shí)候服務(wù)器帶寬也可能導(dǎo)致請(qǐng)求響應(yīng)慢的問(wèn)題
補(bǔ)充：
緩存同時(shí)也指靜態(tài)資源客戶端緩存
cdn緩存，靜態(tài)資源通過(guò)上傳cdn，cdn節(jié)點(diǎn)緩存我們的靜態(tài)資源，減少服務(wù)器壓力
面向服務(wù)
SOA面向服務(wù)架構(gòu)設(shè)計(jì)
微服務(wù)更細(xì)粒度服務(wù)化，一系列的獨(dú)立的服務(wù)共同組成系統(tǒng)
使用服務(wù)化思維，將核心業(yè)務(wù)或者通用的業(yè)務(wù)功能抽離成服務(wù)獨(dú)立部署，對(duì)外提供接口的方式提供功能。
最理想化的設(shè)計(jì)是可以把一個(gè)復(fù)雜的系統(tǒng)抽離成多個(gè)服務(wù)，共同組成系統(tǒng)的業(yè)務(wù)，優(yōu)點(diǎn)：松耦合，高可用性，高伸縮性，易維護(hù)。
通過(guò)面向服務(wù)化設(shè)計(jì)，獨(dú)立服務(wù)器部署，均衡負(fù)載，數(shù)據(jù)庫(kù)集群，可以讓服務(wù)支撐更高的并發(fā)
服務(wù)例子：
用戶行為跟蹤記錄統(tǒng)計(jì)
說(shuō)明：
通過(guò)上報(bào)應(yīng)用模塊，操作事件，事件對(duì)象，等數(shù)據(jù)，記錄用戶的操作行為
比如：記錄用戶在某個(gè)商品模塊，點(diǎn)擊了某一件商品，或者瀏覽了某一件商品
背景：
由于服務(wù)需要記錄用戶的各種操作行為，并且可以重復(fù)上報(bào)，準(zhǔn)備接入服務(wù)的業(yè)務(wù)又是核心業(yè)務(wù)的用戶行為跟蹤，所以請(qǐng)求量很大，高峰期會(huì)產(chǎn)生大量并發(fā)請(qǐng)求。
架構(gòu)：
nodejs WEB應(yīng)用服務(wù)器均衡負(fù)載
redis主從集群
mysql主
nodejs+express+ejs+redis+mysql
服務(wù)端采用nodejs,nodejs是單進(jìn)程（PM2根據(jù)cpu核數(shù)開(kāi)啟多個(gè)工作進(jìn)程），采用事件驅(qū)動(dòng)機(jī)制，適合I/O密集型業(yè)務(wù)，處理高并發(fā)能力強(qiáng)
業(yè)務(wù)設(shè)計(jì)：
并發(fā)量大，所以不能直接入庫(kù)，采用：異步同步數(shù)據(jù),消息隊(duì)列
請(qǐng)求接口上報(bào)數(shù)據(jù)，接口將上報(bào)數(shù)據(jù)push到redis的list隊(duì)列中
nodejs寫入庫(kù)腳本，循環(huán)pop redis list數(shù)據(jù)，將數(shù)據(jù)存儲(chǔ)入庫(kù)，并進(jìn)行相關(guān)統(tǒng)計(jì)Update，無(wú)數(shù)據(jù)時(shí)sleep幾秒
因?yàn)閿?shù)據(jù)量會(huì)比較大，上報(bào)的數(shù)據(jù)表按天命名存儲(chǔ)
接口：
上報(bào)數(shù)據(jù)接口
統(tǒng)計(jì)查詢接口
上線跟進(jìn)：
服務(wù)業(yè)務(wù)基本正常
每天的上報(bào)表有上千萬(wàn)的數(shù)據(jù)
當(dāng)高并發(fā)業(yè)務(wù)所在的服務(wù)器出現(xiàn)宕機(jī)的時(shí)候，需要有備用服務(wù)器進(jìn)行快速的替代，在應(yīng)用服務(wù)器壓力大的時(shí)候可以快速添加機(jī)器到集群中，所以我們就需要有備用機(jī)器可以隨時(shí)待命。 最理想的方式是可以通過(guò)自動(dòng)化監(jiān)控服務(wù)器資源消耗來(lái)進(jìn)行報(bào)警，自動(dòng)切換降級(jí)方案，自動(dòng)的進(jìn)行服務(wù)器替換和添加操作等，通過(guò)自動(dòng)化可以減少人工的操作的成本，而且可以快速操作，避免人為操作上面的失誤。
冗余
數(shù)據(jù)庫(kù)備份
備用服務(wù)器
自動(dòng)化
自動(dòng)化監(jiān)控
自動(dòng)化報(bào)警
自動(dòng)化降級(jí)
通過(guò)GitLab事件，我們應(yīng)該反思，做了備份數(shù)據(jù)并不代表就萬(wàn)無(wú)一失了，我們需要保證高可用性，首先備份是否正常進(jìn)行，備份數(shù)據(jù)是否可用，需要我們進(jìn)行定期的檢查，或者自動(dòng)化監(jiān)控， 還有包括如何避免人為上的操作失誤問(wèn)題。(不過(guò)事件中g(shù)itlab的開(kāi)放性姿態(tài)，積極的處理方式還是值得學(xué)習(xí)的)
到此，相信大家對(duì)“服務(wù)器的高并發(fā)架構(gòu)實(shí)例分析”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
