服務(wù)器架構(gòu)與高并發(fā)性能測試實(shí)戰(zhàn)方案（二）
- 作者：新網(wǎng)
- 來源：新網(wǎng)
- 瀏覽：100
- 2018-05-10 17:55:04
場景中的這些業(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é)果緩存起來。
3.實(shí)戰(zhàn)方案
<
div>
1)通用方案
日用戶流量大，但是比較分散，偶爾會(huì)有用戶高聚的情況;
場景： 用戶簽到，用戶中心，用戶訂單等。
說明：
場景中的這些業(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é)果緩存起來。
更新用戶相關(guān)緩存需要分布式存儲(chǔ)，比如使用用戶ID進(jìn)行hash分組，把用戶分布到不同的緩存中，這樣一個(gè)緩存集合的總量不會(huì)很大，不會(huì)影響查詢效率。
方案如：
用戶簽到獲取積分：
計(jì)算出用戶分布的key，Redis，hash中查找用戶今日簽到信息
如果查詢到簽到信息，返回簽到信息
如果沒有查詢到，DB查詢今日是否簽到過，如果有簽到過，就把簽到信息同步Redis緩存。
如果DB中也沒有查詢到今日的簽到記錄，就進(jìn)行簽到邏輯，操作DB添加今日簽到記錄，添加簽到積分(這整個(gè)DB操作是一個(gè)事務(wù))
緩存簽到信息到Redis，返回簽到信息
注意這里會(huì)有并發(fā)情況下的邏輯問題，如：一天簽到多次，發(fā)放多次積分給用戶。
用戶訂單：
這里我們只緩存用戶第一頁的訂單信息，一頁40條數(shù)據(jù)，用戶一般也只會(huì)看第一頁的訂單數(shù)據(jù)
用戶訪問訂單列表，如果是第一頁讀緩存，如果不是讀DB
計(jì)算出用戶分布的key，Redis，hash中查找用戶訂單信息
如果查詢到用戶訂單信息，返回訂單信息
如果不存在就進(jìn)行DB查詢第一頁的訂單數(shù)據(jù)，然后緩存redis，返回訂單信息
用戶中心：
計(jì)算出用戶分布的key，Redis hash中查找用戶訂單信息
如果查詢到用戶信息，返回用戶信息
如果不存在進(jìn)行用戶DB查詢，然后緩存redis，返回用戶信息
商品已成功加入購物車