大話程序猿眼里的高并發(fā)架構

前言

高并發(fā)經(jīng)常會發(fā)生在有大活躍用戶量,用戶高聚集的業(yè)務場景中,如:秒殺活動板惑,定時領取紅包等。
為了讓業(yè)務可以流暢的運行并且給用戶一個好的交互體驗偎快,我們需要根據(jù)業(yè)務場景預估達到的并發(fā)量等因素冯乘,來設計適合自己業(yè)務場景的高并發(fā)處理方案。

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


服務器架構

業(yè)務從發(fā)展的初期到逐漸成熟响逢,服務器架構也是從相對單一到集群绒窑,再到分布式服務。
一個可以支持高并發(fā)的服務少不了好的服務器架構舔亭,需要有均衡負載些膨,數(shù)據(jù)庫需要主從集群蟀俊,nosql緩存需要主從集群,靜態(tài)文件需要上傳cdn订雾,這些都是能讓業(yè)務程序流暢運行的強大后盾肢预。

服務器這塊多是需要運維人員來配合搭建,具體我就不多說了洼哎,點到為止烫映。
大致需要用到的服務器架構如下:

  • 服務器
    • 均衡負載(如:nginx,阿里云SLB)
    • 資源監(jiān)控
    • 分布式
  • 數(shù)據(jù)庫
    • 主從分離噩峦,集群
    • DBA 表優(yōu)化锭沟,索引優(yōu)化,等
    • 分布式
  • nosql
    • redis
      • 主從分離识补,集群
    • mongodb
      • 主從分離族淮,集群
    • memcache
      • 主從分離,集群
  • cdn
    • html
    • css
    • js
    • image

并發(fā)測試

高并發(fā)相關的業(yè)務凭涂,需要進行并發(fā)的測試祝辣,通過大量的數(shù)據(jù)分析評估出整個架構可以支撐的并發(fā)量。

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

第三方服務:

  • 阿里云性能測試

并發(fā)測試工具:

  • Apache JMeter
  • Visual Studio性能負載測試
  • Microsoft Web Application Stress Tool

實戰(zhàn)方案

通用方案

日用戶流量大,但是比較分散攻谁,偶爾會有用戶高聚的情況岛琼;

場景: 用戶簽到,用戶中心巢株,用戶訂單,等

服務器架構圖:

說明:

場景中的這些業(yè)務基本是用戶進入APP后會操作到的熙涤,除了活動日(618,雙11阁苞,等),這些業(yè)務的用戶量都不會高聚集祠挫,同時這些業(yè)務相關的表都是大數(shù)據(jù)表那槽,業(yè)務多是查詢操作,所以我們需要減少用戶直接命中DB的查詢等舔;優(yōu)先查詢緩存骚灸,如果緩存不存在,再進行DB查詢慌植,將查詢結(jié)果緩存起來甚牲。

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

方案如:

  • 用戶簽到獲取積分
    • 計算出用戶分布的key,redis hash中查找用戶今日簽到信息
    • 如果查詢到簽到信息雏赦,返回簽到信息
    • 如果沒有查詢到劫笙,DB查詢今日是否簽到過,如果有簽到過星岗,就把簽到信息同步redis緩存填大。
    • 如果DB中也沒有查詢到今日的簽到記錄,就進行簽到邏輯俏橘,操作DB添加今日簽到記錄允华,添加簽到積分(這整個DB操作是一個事務)
    • 緩存簽到信息到redis,返回簽到信息
    • 注意這里會有并發(fā)情況下的邏輯問題敷矫,如:一天簽到多次例获,發(fā)放多次積分給用戶。
    • 我的博文[大話程序猿眼里的高并發(fā)]有相關的處理方案曹仗。
  • 用戶訂單
    • 這里我們只緩存用戶第一頁的訂單信息榨汤,一頁40條數(shù)據(jù),用戶一般也只會看第一頁的訂單數(shù)據(jù)
    • 用戶訪問訂單列表怎茫,如果是第一頁讀緩存收壕,如果不是讀DB
    • 計算出用戶分布的key,redis hash中查找用戶訂單信息
    • 如果查詢到用戶訂單信息,返回訂單信息
    • 如果不存在就進行DB查詢第一頁的訂單數(shù)據(jù)轨蛤,然后緩存redis蜜宪,返回訂單信息
  • 用戶中心
    • 計算出用戶分布的key,redis hash中查找用戶訂單信息
    • 如果查詢到用戶信息,返回用戶信息
    • 如果不存在進行用戶DB查詢祥山,然后緩存redis圃验,返回用戶信息
  • 其他業(yè)務
    • 上面例子多是針對用戶存儲緩存,如果是公用的緩存數(shù)據(jù)需要注意一些問題缝呕,如下
    • 注意公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導致大量命中DB查詢澳窑,可以使用管理后臺更新緩存,或者DB查詢的鎖住操作供常。
    • 我的博文[大話Redis進階]對更新緩存問題和推薦方案的分享摊聋。

以上例子是一個相對簡單的高并發(fā)架構挣磨,并發(fā)量不是很高的情況可以很好的支撐榜聂,但是隨著業(yè)務的壯大,用戶并發(fā)量增加嗤锉,我們的架構也會進行不斷的優(yōu)化和演變,比如對業(yè)務進行服務化煎源,每個服務有自己的并發(fā)架構色迂,自己的均衡服務器,分布式數(shù)據(jù)庫薪夕,nosql主從集群脚草,如:用戶服務、訂單服務原献;


消息隊列

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

場景:定時領取紅包姑隅,等

服務器架構圖:

說明:

場景中的定時領取是一個高并發(fā)的業(yè)務写隶,像秒殺活動用戶會在到點的時間涌入,DB瞬間就接受到一記暴擊讲仰,hold不住就會宕機慕趴,然后影響整個業(yè)務;

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

設計這塊業(yè)務的時候就會使用消息隊列的趁矾,可以將參與用戶的信息添加到消息隊列中耙册,然后再寫個多線程程序去消耗隊列,給隊列中的用戶發(fā)放紅包毫捣;

方案如:

  • 定時領取紅包
    • 一般習慣使用 redis的 list
    • 當用戶參與活動详拙,將用戶參與信息push到隊列中
    • 然后寫個多線程程序去pop數(shù)據(jù),進行發(fā)放紅包的業(yè)務
    • 這樣可以支持高并發(fā)下的用戶可以正常的參與活動蔓同,并且避免數(shù)據(jù)庫服務器宕機的危險

附加:
通過消息隊列可以做很多的服務饶辙。
如:定時短信發(fā)送服務,使用sset(sorted set)斑粱,發(fā)送時間戳作為排序依據(jù)弃揽,短信數(shù)據(jù)隊列根據(jù)時間升序,然后寫個程序定時循環(huán)去讀取sset隊列中的第一條则北,當前時間是否超過發(fā)送時間蹋宦,如果超過就進行短信發(fā)送。


一級緩存

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

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

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

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

服務器架構圖:

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


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

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

對于更新頻繁度不高偶妖,并且數(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服務器上。

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


其他方案

  • 對于更新頻繁度不高的數(shù)據(jù)润讥,APP,PC瀏覽器,可以緩存數(shù)據(jù)到本地盘寡,然后每次請求接口的時候上傳當前緩存數(shù)據(jù)的版本號楚殿,服務端接收到版本號判斷版本號與最新數(shù)據(jù)版本號是否一致,如果不一樣就進行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號竿痰,如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新脆粥。減少服務器壓力:資源、帶寬

歡迎工作一到五年的Java工程師朋友們加入Java高并發(fā): 957734884影涉,群內(nèi)提供免費的Java架構學習資料(里面有高可用变隔、高并發(fā)、高性能及分布式蟹倾、Jvm性能調(diào)優(yōu)匣缘、Spring源碼猖闪,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用自己每一分每一秒的時間來學習提升自己肌厨,不要再用"沒有時間“來掩飾自己思想上的懶惰培慌!趁年輕,使勁拼柑爸,給未來的自己一個交代吵护!

版權申明:內(nèi)容來源網(wǎng)絡,版權歸原創(chuàng)者所有表鳍。除非無法確認馅而,我們都會標明作者及出處,如有侵權煩請告知进胯,我們會立即刪除并表示歉意用爪。謝謝

最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市胁镐,隨后出現(xiàn)的幾起案子偎血,更是在濱河造成了極大的恐慌,老刑警劉巖盯漂,帶你破解...
    沈念sama閱讀 216,692評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件颇玷,死亡現(xiàn)場離奇詭異,居然都是意外死亡就缆,警方通過查閱死者的電腦和手機帖渠,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,482評論 3 392
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來竭宰,“玉大人空郊,你說我怎么就攤上這事∏薪遥” “怎么了狞甚?”我有些...
    開封第一講書人閱讀 162,995評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長廓旬。 經(jīng)常有香客問我哼审,道長,這世上最難降的妖魔是什么孕豹? 我笑而不...
    開封第一講書人閱讀 58,223評論 1 292
  • 正文 為了忘掉前任涩盾,我火速辦了婚禮,結(jié)果婚禮上励背,老公的妹妹穿的比我還像新娘春霍。我一直安慰自己,他們只是感情好叶眉,可當我...
    茶點故事閱讀 67,245評論 6 388
  • 文/花漫 我一把揭開白布址儒。 她就那樣靜靜地躺著籍胯,像睡著了一般。 火紅的嫁衣襯著肌膚如雪离福。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,208評論 1 299
  • 那天炼蛤,我揣著相機與錄音妖爷,去河邊找鬼。 笑死理朋,一個胖子當著我的面吹牛絮识,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播嗽上,決...
    沈念sama閱讀 40,091評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼次舌,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了兽愤?” 一聲冷哼從身側(cè)響起彼念,我...
    開封第一講書人閱讀 38,929評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎浅萧,沒想到半個月后逐沙,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,346評論 1 311
  • 正文 獨居荒郊野嶺守林人離奇死亡洼畅,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,570評論 2 333
  • 正文 我和宋清朗相戀三年吩案,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片帝簇。...
    茶點故事閱讀 39,739評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡徘郭,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出丧肴,到底是詐尸還是另有隱情残揉,我是刑警寧澤,帶...
    沈念sama閱讀 35,437評論 5 344
  • 正文 年R本政府宣布闪湾,位于F島的核電站冲甘,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏途样。R本人自食惡果不足惜江醇,卻給世界環(huán)境...
    茶點故事閱讀 41,037評論 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望何暇。 院中可真熱鬧陶夜,春花似錦、人聲如沸裆站。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,677評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至羽嫡,卻和暖如春本姥,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背杭棵。 一陣腳步聲響...
    開封第一講書人閱讀 32,833評論 1 269
  • 我被黑心中介騙來泰國打工婚惫, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人魂爪。 一個月前我還...
    沈念sama閱讀 47,760評論 2 369
  • 正文 我出身青樓先舷,卻偏偏與公主長得像,于是被迫代替她去往敵國和親滓侍。 傳聞我的和親對象是個殘疾皇子蒋川,可洞房花燭夜當晚...
    茶點故事閱讀 44,647評論 2 354