SpringBoot整合Redis實現常用功能超詳細過程
SpringBoot整合Redis實現常用功能建議大小伙們,在寫業(yè)務的時候,提前畫好流程圖,思路會清晰很多。文末有解決緩存穿透和擊穿的通用工具類。
1 登陸功能
我想,登陸功能是每個項目必備的功能吧,但是想設計好,卻是很難!下面介紹兩種登陸功能的解決方式:
- 基于Session實現登錄流程
- 基于Redis實現登錄流程
1.1 基于Session實現登錄流程
功能流程:
發(fā)送驗證碼:
用戶在提交手機號后,會校驗手機號是否合法,如果不合法,則要求用戶重新輸入手機號
如果手機號合法,后臺此時生成對應的驗證碼,同時將驗證碼進行保存,然后再通過短信的方式將驗證碼發(fā)送給用戶
短信驗證碼登錄、注冊:
- 用戶將驗證碼和手機號進行輸入,后臺從session中拿到當前驗證碼,然后和用戶輸入的驗證碼進行校驗,如果不一致,則無法通過校驗,如果一致,則后臺根據手機號查詢用戶,
- 如果用戶不存在,則為用戶創(chuàng)建賬號信息,保存到數據庫,無論是否存在,都會將用戶信息保存到session中,方便后續(xù)獲得當前登錄信息
校驗登錄狀態(tài):
- 用戶在請求時候,會從cookie中攜帶者JsessionId到后臺,后臺通過JsessionId從session中拿到用戶信息,如果沒有session信息,則進行攔截,如果有session信息,則
- 將用戶信息保存到threadLocal中,并且放行

1.1.1 session共享問題
基于session方式實現登陸功能,最大的缺點就是在多臺tomcat下session無法共享,就會下出現下面問題。
核心思路分析:
每個tomcat中都有一份屬于自己的session,假設用戶第一次訪問第一臺tomcat,并且把自己的信息存放到第一臺服務器的session中,但是第二次這個用戶訪問到了第二臺tomcat,那么在第二臺服務器上,肯定沒有第一臺服務器存放的session,所以此時 整個登錄攔截功能就會出現問題,我們能如何解決這個問題呢?早期的方案是session拷貝,就是說雖然每個tomcat上都有不同的session,但是每當任意一臺服務器的session修改時,都會同步給其他的Tomcat服務器的session,這樣的話,就可以實現session的共享了
但是這種方案具有兩個大問題
1、每臺服務器中都有完整的一份session數據,服務器壓力過大。
2、session拷貝數據時,可能會出現延遲
所以咱們后來采用的方案都是基于redis來完成,我們把session換成redis,redis數據本身就是共享的,就可以避免session共享的問題了

1.2 Redis替代Session
1.2.1、設計key的結構
首先我們要思考一下利用redis來存儲數據,那么到底使用哪種結構呢?由于存入的數據比較簡單,我們可以考慮使用String,或者是使用哈希,如下圖,如果使用String,同學們注意他的value,用多占用一點空間,如果使用哈希,則他的value中只會存儲他數據本身,如果不是特別在意內存,其實使用String就可以啦。

1.2.2、設計key的具體細節(jié)
所以我們可以使用String結構,就是一個簡單的key,value鍵值對的方式,但是關于key的處理,session他是每個用戶都有自己的session,但是redis的key是共享的,咱們就不能使用code了
在設計這個key的時候,我們之前講過需要滿足兩點:
1、key要具有唯一性2、key要方便攜帶
如果我們采用phone:手機號這個的數據來存儲當然是可以的,但是如果把這樣的敏感數據存儲到redis中并且從頁面中帶過來畢竟不太合適,所以我們在后臺生成一個隨機串token,然后讓前端帶來這個token就能完成我們的整體邏輯了.
1.2.3、整體訪問流程
當注冊完成后,用戶去登錄會去校驗用戶提交的手機號和驗證碼,是否一致,如果一致,則根據手機號查詢用戶信息,不存在則新建,最后將用戶數據保存到redis,并且生成token作為redis的key,當我們校驗用戶是否登錄時,會去攜帶著token進行訪問,從redis中取出token對應的value,判斷是否存在這個數據,如果沒有則攔截,如果存在則將其保存到threadLocal中,并且放行。

2 緩存功能
2.1 什么是緩存?
緩存(Cache),就是數據交換的緩沖區(qū),俗稱的緩存就是緩沖區(qū)內的數據,一般從數據庫中獲取,存儲于本地代碼(例如:
例1:Static final ConcurrentHashMap<K,V> map = new ConcurrentHashMap<>(); 本地用于高并發(fā) 例2:static final Cache<K,V> USER_CACHE = CacheBuilder.newBuilder().build(); 用于redis等緩存 例3:Static final Map<K,V> map = new HashMap(); 本地緩存
由于其被Static修飾,所以隨著類的加載而被加載到內存之中,作為本地緩存,由于其又被final修飾,所以其引用(例3:map)和對象(例3:new HashMap())之間的關系是固定的,不能改變,因此不用擔心賦值(=)導致緩存失效;
2.1.1 為什么要使用緩存
一句話:因為速度快,好用
緩存數據存儲于代碼中,而代碼運行在內存中,內存的讀寫性能遠高于磁盤,緩存可以大大降低用戶訪問并發(fā)量帶來的服務器讀寫壓力
實際開發(fā)過程中,企業(yè)的數據量,少則幾十萬,多則幾千萬,這么大數據量,如果沒有緩存來作為"避震器",系統(tǒng)是幾乎撐不住的,所以企業(yè)會大量運用到緩存技術;
但是緩存也會增加代碼復雜度和運營的成本:

2.1.2 如何使用緩存
實際開發(fā)中,會構筑多級緩存來使系統(tǒng)運行速度進一步提升,例如:本地緩存與redis中的緩存并發(fā)使用
瀏覽器緩存:主要是存在于瀏覽器端的緩存
應用層緩存:可以分為tomcat本地緩存,比如之前提到的map,或者是使用redis作為緩存
數據庫緩存:在數據庫中有一片空間是 buffer pool,增改查數據都會先加載到mysql的緩存中
CPU緩存:當代計算機最大的問題是 cpu性能提升了,但內存讀寫速度沒有跟上,所以為了適應當下的情況,增加了cpu的L1,L2,L3級的緩存

2.2.使用緩存
2.2.1 、緩存模型和思路
標準的操作方式就是查詢數據庫之前先查詢緩存,如果緩存數據存在,則直接從緩存中返回,如果緩存數據不存在,再查詢數據庫,然后將數據存入redis

2.3 緩存更新策略
緩存更新是redis為了節(jié)約內存而設計出來的一個東西,主要是因為內存數據寶貴,當我們向redis插入太多數據,此時就可能會導致緩存中的數據過多,所以redis會對部分數據進行更新,或者把他叫為淘汰更合適。
內存淘汰:redis自動進行,當redis內存達到咱們設定的max-memery的時候,會自動觸發(fā)淘汰機制,淘汰掉一些不重要的數據(可以自己設置策略方式)
超時剔除:當我們給redis設置了過期時間ttl之后,redis會將超時的數據進行刪除,方便咱們繼續(xù)使用緩存
主動更新:我們可以手動調用方法把緩存刪掉,通常用于解決緩存和數據庫不一致問題

2.3.1 、數據庫緩存不一致解決方案:
由于我們的緩存的數據源來自于數據庫,而數據庫的數據是會發(fā)生變化的,因此,如果當數據庫中數據發(fā)生變化,而緩存卻沒有同步,此時就會有一致性問題存在,其后果是:
用戶使用緩存中的過時數據,就會產生類似多線程數據安全問題,從而影響業(yè)務,產品口碑等;怎么解決呢?有如下幾種方案
Cache Aside Pattern 人工編碼方式:緩存調用者在更新完數據庫后再去更新緩存,也稱之為雙寫方案(一般采用)
Read/Write Through Pattern : 由系統(tǒng)本身完成,數據庫與緩存的問題交由系統(tǒng)本身去處理
Write Behind Caching Pattern :調用者只操作緩存,其他線程去異步處理數據庫,實現最終一致

2.3.2 、數據庫和緩存不一致采用什么方案
綜合考慮使用方案一,但是方案一調用者如何處理呢?這里有幾個問題
操作緩存和數據庫時有三個問題需要考慮:
如果采用第一個方案,那么假設我們每次操作數據庫后,都操作緩存,但是中間如果沒有人查詢,那么這個更新動作實際上只有最后一次生效,中間的更新動作意義并不大,我們可以把緩存刪除,等待再次查詢時,將緩存中的數據加載出來
- 刪除緩存還是更新緩存?
- 更新緩存:每次更新數據庫都更新緩存,無效寫操作較多
- 刪除緩存:更新數據庫時讓緩存失效,查詢時再更新緩存
- 如何保證緩存與數據庫的操作的同時成功或失敗?
- 單體系統(tǒng),將緩存與數據庫操作放在一個事務
- 分布式系統(tǒng),利用TCC等分布式事務方案
應該具體操作緩存還是操作數據庫,我們應當是先操作數據庫,再刪除緩存,原因在于,如果你選擇第一種方案,在兩個線程并發(fā)來訪問時,假設線程1先來,他先把緩存刪了,此時線程2過來,他查詢緩存數據并不存在,此時他寫入緩存,當他寫入緩存后,線程1再執(zhí)行更新動作時,實際上寫入的就是舊的數據,新的數據被舊數據覆蓋了。
- 先操作緩存還是先操作數據庫?
- 先刪除緩存,再操作數據庫(
存在線程安全問題) - 先操作數據庫,再刪除緩存

2.4 緩存穿透問題的解決思路
緩存穿透 :緩存穿透是指客戶端請求的數據在緩存中和數據庫中都不存在,這樣緩存永遠不會生效,這些請求都會打到數據庫。
常見的解決方案有兩種:
- 緩存空對象
- 優(yōu)點:實現簡單,維護方便
- 缺點:
- 額外的內存消耗
- 可能造成短期的不一致
- 布隆過濾
- 優(yōu)點:內存占用較少,沒有多余key
- 缺點:
- 實現復雜
- 存在誤判可能
緩存空對象思路分析:當我們客戶端訪問不存在的數據時,先請求redis,但是此時redis中沒有數據,此時會訪問到數據庫,但是數據庫中也沒有數據,這個數據穿透了緩存,直擊數據庫,我們都知道數據庫能夠承載的并發(fā)不如redis這么高,如果大量的請求同時過來訪問這種不存在的數據,這些請求就都會訪問到數據庫,簡單的解決方案就是哪怕這個數據在數據庫中也不存在,我們也把這個數據存入到redis中去,這樣,下次用戶過來訪問這個不存在的數據,那么在redis中也能找到這個數據就不會進入到緩存了.
布隆過濾:布隆過濾器其實采用的是哈希思想來解決這個問題,通過一個龐大的二進制數組,走哈希思想去判斷當前這個要查詢的這個數據是否存在,如果布隆過濾器判斷存在,則放行,這個請求會去訪問redis,哪怕此時redis中的數據過期了,但是數據庫中一定存在這個數據,在數據庫中查詢出來這個數據后,再將其放入到redis中
假設布隆過濾器判斷這個數據不存在,則直接返回
這種方式優(yōu)點在于節(jié)約內存空間,存在誤判,誤判原因在于:布隆過濾器走的是哈希思想,只要哈希思想,就可能存在哈希沖突

小總結:
緩存穿透產生的原因是什么?
- 用戶請求的數據在緩存中和數據庫中都不存在,不斷發(fā)起這樣的請求,給數據庫帶來巨大壓力
緩存穿透的解決方案有哪些?
- 緩存null值
- 布隆過濾
- 增強id的復雜度,避免被猜測id規(guī)律
- 做好數據的基礎格式校驗
- 加強用戶權限校驗
- 做好熱點參數的限流
3.工具類
此工具類已經對緩存穿透,和緩存擊穿實現了通用功能。
可以對比上敘的流程圖查閱
import cn.hutool.core.util.BooleanUtil;
import cn.hutool.core.util.StrUtil;
import cn.hutool.json.JSONObject;
import cn.hutool.json.JSONUtil;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;
import javax.annotation.Resource;
import java.time.LocalDateTime;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.function.Function;
import static com.hmdp.utils.RedisConstants.CACHE_NULL_TTL;
/**
* @author : look-word
* 2022-08-19 17:02
**/
@Component
public class CacheClient {
@Resource
private StringRedisTemplate stringRedisTemplate;
public void set(String key, Object value, Long time, TimeUnit unit) {
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value), time, unit);
}
/**
* 設置邏輯過期時間
*/
public void setWithLogicalExpire(String key, Object value, Long time, TimeUnit unit) {
// .封裝邏輯時間
RedisData redisData = new RedisData();
redisData.setExpireTime(LocalDateTime.now().plusSeconds(unit.toSeconds(time)));
redisData.setData(value);
String redisDataJson = JSONUtil.toJsonStr(redisData);
// 寫入Redis
stringRedisTemplate.opsForValue().set(key, redisDataJson);
}
/**
* 解決緩存穿透 對未存在的數據 設置為null
*/
public <R, ID> R queryWithPassThrough
(String keyPrefix, ID id, Class<R> type, Function<ID, R> dbFallback, Long cacheTime, TimeUnit cacheUnit) {
// 緩存key
String key = keyPrefix + id;
// 1 查詢緩存中是否命中
String json = stringRedisTemplate.opsForValue().get(key);
if (StrUtil.isNotBlank(json)) {
R r = JSONUtil.toBean(json, type);
return r;
}
// 解決緩存穿透 數據庫不存在的數據 緩存 也不存在 惡意請求
if (json != null) {
return null;
}
// 2 查詢數據庫 存在 存入緩存 返回給前端
R r = dbFallback.apply(id);
if (r == null) {
// 解決緩存穿透
stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
// 2.1 轉換成json 存入緩存中
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(r), cacheTime, cacheUnit);
return r;
}
// 線程池
public static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);
/**
* 解決緩存擊穿 邏輯過期時間方式
*/
public <R, ID> R queryWithLogicalExpire
(String keyPrefix, ID id, Class<R> type, String lockKeyPrefix, Function<ID, R> dbFallback, Long expiredTime, TimeUnit expiredUnit) {
// 緩存key
String key = keyPrefix + id;
// 1 查詢緩存中是否命中
String redisDataJson = stringRedisTemplate.opsForValue().get(key);
if (StrUtil.isBlank(redisDataJson)) {
return null;
}
// 2.命中 查看是否過期,
// 2.1 未過期 直接返回舊數據
// 2.2 過期 獲取鎖 查詢數據寫入Redis設置新的過期時間
// 2.3 過期 未獲取鎖 返回 舊數據
RedisData redisData = JSONUtil.toBean(redisDataJson, RedisData.class);
LocalDateTime expireTime = redisData.getExpireTime();
R r = JSONUtil.toBean((JSONObject) redisData.getData(), type);
if (LocalDateTime.now().isBefore(expireTime)) {
return r;
}
String lockKey = lockKeyPrefix + id;
// 獲取鎖
boolean isLock = tryLock(lockKey);
if (isLock) {
CACHE_REBUILD_EXECUTOR.submit(() -> {
try {
// 查詢數據庫
R r1 = dbFallback.apply(id);
// 存儲Redis 設置邏輯過期 過期時間
setWithLogicalExpire(key, r1, expiredTime, expiredUnit);
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
// 釋放鎖
unlock(lockKey);
}
});
}
// 未獲取到鎖
return r;
}
/**
* 獲取鎖
*/
public boolean tryLock(String key) {
Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 100, TimeUnit.SECONDS);
return BooleanUtil.isTrue(flag);
}
/**
* 釋放鎖
*/
public void unlock(String key) {
stringRedisTemplate.delete(key);
}
}
到此這篇關于SpringBoot整合Redis實現常用功能超詳細過程的文章就介紹到這了,更多相關SpringBoot整合Redis內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

