web中高并發(fā)架構(gòu)的示例分析

這篇文章將為大家詳細講解有關(guān)web中高并發(fā)架構(gòu)的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

為大祥等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及大祥網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站建設(shè)、成都做網(wǎng)站、大祥網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

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

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

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

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

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

• 服務(wù)器

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

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

第三方服務(wù):

• 阿里云性能測試

并發(fā)測試工具：

• Apache JMeter

• Visual Studio性能負載測試

• Microsoft Web Application Stress Tool

---

實戰(zhàn)方案

通用方案

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

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

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

說明：

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

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

方案如：

• 用戶簽到獲取積分

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

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

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

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

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

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

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

• 用戶訂單

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

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

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

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

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

• 用戶中心

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

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

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

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

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

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

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

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

---

消息隊列

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

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

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

說明：

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

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

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

方案如：

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

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

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

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

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

附加：

通過消息隊列可以做很多的服務(wù)。

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

---

一級緩存

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

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

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

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

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

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

---

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

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

對于更新頻繁度不高，并且數(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服務(wù)器上。

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

針對上面的技術(shù)我特意整理了一下，有很多技術(shù)不是靠幾句話能講清楚，所以干脆找朋友錄制了一些視頻，很多問題其實很簡單，但是背后的思考和邏輯不簡單，要做到知其然還要知其所以然。費分享給大家。

其他方案

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

關(guān)于“web中高并發(fā)架構(gòu)的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

網(wǎng)站題目：web中高并發(fā)架構(gòu)的示例分析
標題鏈接：http://bm7419.com/article4/jdsjie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、域名注冊、響應(yīng)式網(wǎng)站、靜態(tài)網(wǎng)站、建站公司、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)