分享一個簡單的小需求應該怎麼設計實現以及有關Redis的使用
Redis
在實際應用中使用的非常廣泛,本篇文章就從一個簡單的需求說起,爲你講述一個需求是如何從頭到尾開始做的,又是如何一步步完善的。之前寫過一篇《如何實現頁面廣告隨時上下線、過期自動下線及到時自動上線》,也涉及到了Redis
在項目中的實際應用,有興趣的可以看一下。
需求
設定,現在我們有一個APP,產品新提出一個叫“程序員樹洞”的功能,具體功能就不說了,其中這個功能有一點需要做的是在使用該功能時,如果是首次進入會展示一個協議頁面,用戶需要勾選後點確定才能進入功能,此後再進該功能,不再顯示協議頁直接進入該功能。如下圖所示,
原型圖
需求分析
需求就是這麼的簡單,我們來分析一下。
1、用戶點擊該功能時前端需要知道該給用戶顯示哪個頁面,這一步需要請求後端接口,後臺告訴前端這個用戶有沒有同意過協議。
2、用戶勾選協議點確定,後端需要記錄這步操作(記錄用戶已經同意協議),這一步需在點確定時前端請求後端接口。
概要設計
前面需求分析裏說了,後端需要告訴前端用戶有沒有統一過協議,所以後端需要把這個信息記錄下來,最好是記錄到數據庫保存,那就需要一張表來記錄同意過協議的用戶。表結構大致是:id,客戶號,插入時間。
詳細設計
1、記錄客戶是否已同意過協議並提供查詢功能(查詢是否同意過協議)
2、沒有同意過的和同意過的用戶信息怎麼存儲
3、如何高效的查詢是否同意過
4、怎麼保證高併發下服務的可用性,數據庫的可用性
功能實現
後端提供兩個接口,
1、hasAgree(),查詢該用戶是否已同意協議
2、recordAgree(),記錄用戶已同意協議
第一版 Just DB
很容易嘛!不就是CRUD嗎,小意思。用戶進來先查數據庫有沒有記錄,沒有返回用戶沒有同意過協議,前端給用戶展示協議頁,否則展示功能頁;用戶點同意後,後臺記錄用戶已點了同意協議,記錄到庫。一個查詢一個插入,5分鐘搞定嘛。
直接甩代碼
@ResponseBody@RequestMapping("/hasAgree")
public Map<String,Object> hasAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String custNo = SessionUtil.getUserAttr("CUST_NO",String.class);//客戶號
//query in DB
Map<String,Object> userAgreeInfo = aggreementService.queryUserAgreeInfo(custNo);
//0沒有勾選過同意協議 1已經勾選過同意協議
response.put("hasAgree", MapUtils.isEmpty(userAgreeInfo)?"0":"1";);
return response;
}
@ResponseBody@RequestMapping("/recordAgree")
public Map<String,Object> recordAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String custNo = SessionUtil.getUserAttr("CUST_NO",String.class);//客戶號
Long result = aggreementService.recordUserAgreeInfo(custNo);//add into DB
if(1==result){
response.put("STATUS","1");
response.put("MSG","成功");
}else{
response.put("STATUS","0");
response.put("MSG","失敗");
}
return response;
}
第一版代碼如上,我覺得剛入門的程序員都能夠寫出來。如果用戶量不大,該功能的點擊量不大的話,這麼做還是勉強說得過去。爲什麼說勉強說得過去,因爲存在隱患,你看啊如果每次點擊都會去查庫,假如有人惡意攻擊,仿造高併發,瞬時大量請求過來都去查庫,很可能數據庫頂不住就掛了。或者就算數據庫沒掛,每次查庫也都是浪費啊。所以這是個隱患,或者潛在的危險,那麼第二版我們就去解決這個問題。
第二版 引入Redis緩存
考慮到每次查庫很浪費,那我們使用緩存好不好?
進來先查緩存有沒有對應的數據,緩存裏有就直接返回,沒有則查庫,庫裏有就存緩存。這樣redis就分擔了一部分數據庫的壓力。
代碼呈上
@ResponseBody@RequestMapping("/hasAgree")
public Map<String,Object> hasAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String custNo = SessionUtil.getUserAttr("CUST_NO", String.class);//客戶號
//SISMEMBER key member 判斷 member 元素是否是集合 key 的成員
if(CacheUtil.isMemberRedisSet("HAS_AGREE_USERS",custNo)){
response.put("hasAgree","1"); //已經勾選過同意協議
return response;
}
//query in DB
Map<String,Object> userAgreeInfo = aggreementService.queryUserAgreeInfo(custNo);
if(MapUtils.isEmpty(userAgreeInfo)){
response.put("hasAgree","0"); //沒有勾選過同意協議
}else{
//使用redis的set數據類型,追加到其中
CacheUtil.saddRedisSet("HAS_AGREE_USERS", custNo);
response.put("hasAgree","1"); //已經勾選過同意協議
}
return response;
}
@ResponseBody@RequestMapping("/recordAgree")
public Map<String,Object> recordAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String custNo = SessionUtil.getUserAttr("CUST_NO", String.class);//客戶號
Long result = aggreementService.recordUserAgreeInfo(custNo);//add to DB
if(1==result){
//使用redis的set數據類型,追加到其中
CacheUtil.saddRedisSet("HAS_AGREE_USERS", custNo);
response.put("STATUS","1");
response.put("MSG","成功");
}else{
response.put("STATUS","0");
response.put("MSG","失敗");
}
return response;
}
這一版好一點了,部分請求分攤到redis了,減輕了數據庫的壓力。
第三版 解決緩存穿透
隨着客戶量的增加,點擊這個功能的次數、頻率越來越高,假如有人頻繁點擊該功能,彈出協議後,退出,再點,再退出…就是不點確定
這樣會有啥問題?
這樣的話後臺緩存中沒有,數據庫中也沒有,每次都會走數據庫,繞過了緩存,直接都走數據庫,這類請求量多了也是個問題,這就是緩存穿透。所以第三版,我們來解決緩存穿透的問題。
解決緩存穿透:
因爲是數據庫和緩存都沒有,我們可以讓數據庫沒有的也存到redis。需要改變redis的數據類型,由set改爲map,目的是記錄狀態值。
@ResponseBody@RequestMapping("/hasAgree")
public Map<String,Object> hasAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String hasAgree = "0";
String custNo = SessionUtil.getUserAttr("CUST_NO", String.class);//客戶號
String value = CacheUtil.hgetRedisHash("HAS_AGREE_USERS", custNo, String.class);
if("1".equals(value)){
hasAgree = "1"; //已經勾選過同意協議
}else if("0".equals(value)){
hasAgree = "0";
}else{
//query in DB
Map<String,Object> userAgreeInfo = aggreementService.queryUserAgreeInfo(custNo);
hasAgree = MapUtils.isEmpty(userAgreeInfo)?"0":"1";
//使用redis的hash數據類型
CacheUtil.hsetRedisHash("HAS_AGREE_USERS", custNo, hasAgree);
}
response.put("hasAgree",hasAgree);
return response;
}
@ResponseBody@RequestMapping("/recordAgree")
public Map<String,Object> recordAgree(){
Map<String,Object> response = new HashMap<String,Object>();
String custNo = SessionUtil.getUserAttr("CUST_NO", String.class);//客戶號
Long result = 0;
String hasAgree = "0";
try{
result = aggreementService.recordUserAgreeInfo(custNo);//add to DB
}catch(Exception e){
logger.error("recordUserAgreeInfo error:{}",e)
}
if(1==result){
hasAgree = "1";//入庫成功
response.put("STATUS","1");
response.put("MSG","成功");
}else{
response.put("STATUS","0");
response.put("MSG","失敗");
}
CacheUtil.hsetRedisHash("HAS_AGREE_USERS", custNo, hasAgree);//update or del
return response;
}
可以看到,我們的這個key-field-value沒有設置過期時間,因爲可以認爲這個key是一個熱點key,對於熱點key我們的處理方式是,永久有效或過期時間儘量長一點。
第四版 緩存預熱防止緩存擊穿
另一個關於緩存的問題,那就是緩存擊穿。
何爲緩存擊穿?
假如該功能在前期宣傳力度比較大,或預計該功能上線後點擊量比較大的話,那麼在功能上線後很可能就會一瞬間大量用戶來點擊這個功能,因爲我們前面的邏輯是首次進入該功能的用戶展示協議頁,我們的後臺處理雖然加了redis緩存,但是新上的功能所有用戶都沒有點過,那麼redis裏就沒有緩存,是不是所有用戶的請求都落到數據庫了?一旦瞬間流量非常大,數據庫安全性就存在隱患,有被搞垮的可能。
這個問題就是可以理解爲緩存擊穿。(實際的緩存擊穿是某個key在緩存裏不存在或是失效後,某一瞬間很多請求都來訪問這個key,都判定爲redis裏沒有這個key,就都去查庫。)
所以怎麼解決呢?我們可以在該功能上線前,提前將需要做緩存的數據放入redis,即緩存預熱。
如何預熱?
將所有用戶的信息都放到redis.舉個栗子(也許不是最佳的),我們使用Redis的hash數據結構,key-field-value。key我們可以固定一個字符串如coderTreeHole_Agreement_Check,field我們可以用客戶號(唯一),value是個標誌位,用0代表沒同意過協議,1代表同意過。一般在電商大促前都會對熱點key進行預熱,不然真的扛不住。
and,用戶量很大的時候redis裏的coderTreeHole_Agreement_Check這個key是不是很大?在redis集羣部署模式下,這個key是不是都放在一個節點上?why?
redis3.0上加入了cluster模式,實現的redis的分佈式存儲,也就是說每臺redis節點上存儲不同的內容。在redis的每一個節點上,都有這麼兩個東西,一個是插槽(slot),它的的取值範圍是:0-16383。還有一個就是cluster,可以理解爲是一個集羣管理的插件。當我們的存取的key到達的時候,redis會根據crc16的算法得出一個結果,然後把結果對16384求餘數,這樣每個key都會對應一個編號在0-16383之間的哈希槽,通過這個值,去找到對應的插槽所對應的節點,然後直接自動跳轉到這個對應的節點上進行存取操作。
看了上面這段話,明白了吧。那對於這個大key而且是熱點key的請求,是不是都落到某一個redis節點上了?大key會帶來很多問題,篇幅原因以後再來細說,跑題了。。。
針對這個需求,你還有什麼方法防治緩存擊穿?
第五版 消息隊列削峯填谷
可以看到我們上面的設計其實都是實時對數據庫進行操作的。
例如,當用戶點了同意,前端就調後臺的recordAgree方法將該記錄記錄到數據庫,即這條記錄是立馬插入到數據庫的。
如果剛上線這個功能,大量用戶同時點這個功能,併發量大的話,請求走到後臺,那麼寫庫的操作就非常多,數據庫連接數突然激增,數據庫會頂不住吧。
所以爲避免流量集中落到數據庫,此時我們可以使用消息隊列MQ。將插入操作的請求發往消息隊列,使插入操作以一定的速率到數據庫執行,使得對數據庫的請求數儘量平滑,消息發給消息隊列立即返回給前端成功,不用等待插庫完成,用MQ實現了異步解耦,削峯填谷。
到這你是不是忍不住說設計的真贊~~
另外MQ的使用注意的點還是非常多的,如:消息隊列的消息重複消費問題,順序問題,事務消息等。
總結
對於這個需求設計到哪種程度取決於你的用戶量和併發量,如果是像雙十一那樣,肯定是要用消息隊列的,那一般小的例如,用戶量1千萬,日活10萬,請求最集中的也就是中午9-12點,下午13-17點吧,差不多8個小時,平均一個小時1.25萬,用戶都來點這個功能的話,每分鐘208,每秒3.5,算不上高併發,數據庫完全扛得住。
總結一下,這個需求我們用到的知識點(敲黑板),redis數據緩存
,redis緩存穿透
,緩存擊穿
,熱點key問題
,redis大key問題(沒具體講)
,消息隊列異步解耦
等。
畫圖碼字不易,如果覺得我寫的還可以,記得點贊
鼓勵一下哦,如果覺得有問題歡迎指正
。
886