服務器架構與高并發(fā)性能測試實戰(zhàn)方案（三）
- 作者：新網
- 來源：新網
- 瀏覽：100
- 2018-05-10 17:57:09
上面例子多是針對用戶存儲緩存，如果是公用的緩存數據需要注意一些問題，如：公用的緩存數據需要考慮并發(fā)下的可能會導致大量命中DB查詢，可以使用管理后臺更新緩存，或者DB查詢的鎖住操作。
其他業(yè)務：
<
div>
上面例子多是針對用戶存儲緩存，如果是公用的緩存數據需要注意一些問題，如：公用的緩存數據需要考慮并發(fā)下的可能會導致大量命中DB查詢，可以使用管理后臺更新緩存，或者DB查詢的鎖住操作。
以上例子是一個相對簡單的高并發(fā)架構，并發(fā)量不是很高的情況可以很好的支撐，但是隨著業(yè)務的壯大，用戶并發(fā)量增加，我們的架構也會進行不斷的優(yōu)化和演變，比如對業(yè)務進行服務化，每個服務有自己的并發(fā)架構，自己的均衡
服務器，分布式
數據庫，NoSQL主從集群，如：用戶服務、訂單服務。
2)消息隊列
秒殺、秒搶等活動業(yè)務，用戶在瞬間涌入產生高并發(fā)請求。
場景：定時領取紅包等。
說明：
場景中的定時領取是一個高并發(fā)的業(yè)務，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊，hold不住就會宕機，然后影響整個業(yè)務;
像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數據的業(yè)務，前面提到的通用方案就無法支撐，并發(fā)的時候都是直接命中DB;
設計這塊業(yè)務的時候就會使用消息隊列的，可以將參與用戶的信息添加到消息隊列中，然后再寫個多線程程序去消耗隊列，給隊列中的用戶發(fā)放紅包;
方案如：
定時領取紅包;
一般習慣使用 redis的 list;
當用戶參與活動，將用戶參與信息push到隊列中;
然后寫個多線程程序去pop數據，進行發(fā)放紅包的業(yè)務;
這樣可以支持高并發(fā)下的用戶可以正常的參與活動，并且避免數據庫
服務器宕機的危險。
附加：通過消息隊列可以做很多的服務。
如：定時短信發(fā)送服務，使用sset(sorted set)，發(fā)送時間戳作為排序依據，短信數據隊列根據時間升序，然后寫個程序定時循環(huán)去讀取sset隊列中的第一條，當前時間是否超過發(fā)送時間，如果超過就進行短信發(fā)送。
以上就是我們的今日分享，希望對大家有所幫助。
商品已成功加入購物車