服務(wù)器架構(gòu)與高并發(fā)性能測試實戰(zhàn)方案(三)
- 作者:新網(wǎng)
- 來源:新網(wǎng)
- 瀏覽:100
- 2018-05-10 17:57:09
上面例子多是針對用戶存儲緩存,如果是公用的緩存數(shù)據(jù)需要注意一些問題,如:公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導致大量命中DB查詢,可以使用管理后臺更新緩存,或者DB查詢的鎖住操作。
其他業(yè)務(wù):

<
div>
上面例子多是針對用戶存儲緩存,如果是公用的緩存數(shù)據(jù)需要注意一些問題,如:公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導致大量命中DB查詢,可以使用管理后臺更新緩存,或者DB查詢的鎖住操作。
以上例子是一個相對簡單的高并發(fā)架構(gòu),并發(fā)量不是很高的情況可以很好的支撐,但是隨著業(yè)務(wù)的壯大,用戶并發(fā)量增加,我們的架構(gòu)也會進行不斷的優(yōu)化和演變,比如對業(yè)務(wù)進行服務(wù)化,每個服務(wù)有自己的并發(fā)架構(gòu),自己的均衡
服務(wù)器,分布式
數(shù)據(jù)庫,NoSQL主從集群,如:用戶服務(wù)、訂單服務(wù)。
2)消息隊列
秒殺、秒搶等活動業(yè)務(wù),用戶在瞬間涌入產(chǎn)生高并發(fā)請求。
場景:定時領(lǐng)取紅包等。
說明:
場景中的定時領(lǐng)取是一個高并發(fā)的業(yè)務(wù),像秒殺活動用戶會在到點的時間涌入,DB瞬間就接受到一記暴擊,hold不住就會宕機,然后影響整個業(yè)務(wù);
像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數(shù)據(jù)的業(yè)務(wù),前面提到的通用方案就無法支撐,并發(fā)的時候都是直接命中DB;
設(shè)計這塊業(yè)務(wù)的時候就會使用消息隊列的,可以將參與用戶的信息添加到消息隊列中,然后再寫個多線程程序去消耗隊列,給隊列中的用戶發(fā)放紅包;
方案如:
定時領(lǐng)取紅包;
一般習慣使用 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ā)送。
以上就是我們的今日分享,希望對大家有所幫助。