服務(wù)器架構(gòu)與高并發(fā)性能測試實(shí)戰(zhàn)方案(二)
- 作者:新網(wǎng)
- 來源:新網(wǎng)
- 瀏覽:100
- 2018-05-10 17:55:04
場景中的這些業(yè)務(wù)基本是用戶進(jìn)入APP后會操作到的,除了活動日(618、雙11等),這些業(yè)務(wù)的用戶量都不會高聚集,同時(shí)這些業(yè)務(wù)相關(guān)的表都是大數(shù)據(jù)表,業(yè)務(wù)多是查詢操作,所以我們需要減少用戶直接命中DB的查詢;優(yōu)先查詢緩存,如果緩存不存在,再進(jìn)行DB查詢,將查詢結(jié)果緩存起來。
3.實(shí)戰(zhàn)方案
<
div>
1)通用方案
日用戶流量大,但是比較分散,偶爾會有用戶高聚的情況;
場景: 用戶簽到,用戶中心,用戶訂單等。
說明:
場景中的這些業(yè)務(wù)基本是用戶進(jìn)入APP后會操作到的,除了活動日(618、
雙11等),這些業(yè)務(wù)的用戶量都不會高聚集,同時(shí)這些業(yè)務(wù)相關(guān)的表都是大數(shù)據(jù)表,業(yè)務(wù)多是查詢操作,所以我們需要減少用戶直接命中DB的查詢;優(yōu)先查詢緩存,如果緩存不存在,再進(jìn)行DB查詢,將查詢結(jié)果緩存起來。
更新用戶相關(guān)緩存需要分布式存儲,比如使用用戶ID進(jìn)行hash分組,把用戶分布到不同的緩存中,這樣一個(gè)緩存集合的總量不會很大,不會影響查詢效率。
方案如:
用戶簽到獲取積分:
計(jì)算出用戶分布的key,Redis,hash中查找用戶今日簽到信息
如果查詢到簽到信息,返回簽到信息
如果沒有查詢到,DB查詢今日是否簽到過,如果有簽到過,就把簽到信息同步Redis緩存。
如果DB中也沒有查詢到今日的簽到記錄,就進(jìn)行簽到邏輯,操作DB添加今日簽到記錄,添加簽到積分(這整個(gè)DB操作是一個(gè)事務(wù))
緩存簽到信息到Redis,返回簽到信息
注意這里會有并發(fā)情況下的邏輯問題,如:一天簽到多次,發(fā)放多次積分給用戶。
用戶訂單:
這里我們只緩存用戶第一頁的訂單信息,一頁40條數(shù)據(jù),用戶一般也只會看第一頁的訂單數(shù)據(jù)
用戶訪問訂單列表,如果是第一頁讀緩存,如果不是讀DB
計(jì)算出用戶分布的key,Redis,hash中查找用戶訂單信息
如果查詢到用戶訂單信息,返回訂單信息
如果不存在就進(jìn)行DB查詢第一頁的訂單數(shù)據(jù),然后緩存redis,返回訂單信息
用戶中心:
計(jì)算出用戶分布的key,Redis hash中查找用戶訂單信息
如果查詢到用戶信息,返回用戶信息
如果不存在進(jìn)行用戶DB查詢,然后緩存redis,返回用戶信息