您好,登錄后才能下訂單哦!
今天小編給大家分享一下SpringBoot怎么整合Redis實現常用功能的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
我想,登陸功能
是每個項目必備的功能吧,但是想設計好,卻是很難!下面介紹兩種登陸功能的解決方式:
基于Session實現登錄流程
基于Redis實現登錄流程
功能流程:
發送驗證碼:
用戶在提交手機號后,會校驗手機號是否合法,如果不合法,則要求用戶重新輸入手機號
如果手機號合法,后臺此時生成對應的驗證碼,同時將驗證碼進行保存,然后再通過短信的方式將驗證碼發送給用戶
短信驗證碼登錄、注冊:
用戶將驗證碼和手機號進行輸入,后臺從session中拿到當前驗證碼,然后和用戶輸入的驗證碼進行校驗,如果不一致,則無法通過校驗,如果一致,則后臺根據手機號查詢用戶,
如果用戶不存在,則為用戶創建賬號信息,保存到數據庫,無論是否存在,都會將用戶信息保存到session中,方便后續獲得當前登錄信息
校驗登錄狀態:
用戶在請求時候,會從cookie中攜帶者JsessionId到后臺,后臺通過JsessionId從session中拿到用戶信息,如果沒有session信息,則進行攔截,如果有session信息,則
將用戶信息保存到threadLocal中,并且放行
基于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共享的問題了
首先我們要思考一下利用redis來存儲數據,那么到底使用哪種結構呢?由于存入的數據比較簡單,我們可以考慮使用String,或者是使用哈希,如下圖,如果使用String,同學們注意他的value,用多占用一點空間,如果使用哈希,則他的value中只會存儲他數據本身,如果不是特別在意內存,其實使用String就可以啦。
所以我們可以使用String結構,就是一個簡單的key,value鍵值對的方式,但是關于key的處理,session他是每個用戶都有自己的session,但是redis的key是共享的,咱們就不能使用code了
在設計這個key的時候,我們之前講過需要滿足兩點:
1、key要具有唯一性2、key要方便攜帶
如果我們采用phone
:手機號這個的數據來存儲當然是可以的,但是如果把這樣的敏感數據存儲到redis中并且從頁面中帶過來畢竟不太合適,所以我們在后臺生成一個隨機串token
,然后讓前端帶來這個token就能完成我們的整體邏輯了.
當注冊完成后,用戶去登錄會去校驗用戶提交的手機號和驗證碼
,是否一致,如果一致,則根據手機號查詢用戶信息,不存在則新建
,最后將用戶數據保存到redis,并且生成token作為redis的key,當我們校驗用戶是否登錄時,會去攜帶著token進行訪問,從redis中取出token對應的value,判斷是否存在這個數據,如果沒有則攔截,如果存在則將其保存到threadLocal中,并且放行。
緩存(Cache),就是數據交換的緩沖區,俗稱的緩存就是緩沖區內的數據,一般從數據庫中獲取,存儲于本地代碼(例如:
例1:Static final ConcurrentHashMap<K,V> map = new ConcurrentHashMap<>(); 本地用于高并發 例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())之間的關系是固定的,不能改變,因此不用擔心賦值(=)導致緩存失效;
一句話:因為速度快,好用
緩存數據存儲于代碼中,而代碼運行在內存中,內存的讀寫性能遠高于磁盤,緩存可以大大降低用戶訪問并發量帶來的
服務器讀寫壓力
實際開發過程中,企業的數據量,少則幾十萬,多則幾千萬,這么大數據量,如果沒有緩存來作為"避震器",系統是幾乎撐不住的,所以企業會大量運用到緩存技術;
但是緩存也會增加代碼復雜度和運營的成本:
實際開發中,會構筑多級緩存來使系統運行速度進一步提升,例如:本地緩存與redis中的緩存并發使用
瀏覽器緩存:主要是存在于瀏覽器端的緩存
應用層緩存:可以分為tomcat本地緩存,比如之前提到的map,或者是使用redis作為緩存
數據庫緩存:在數據庫中有一片空間是 buffer pool,增改查數據都會先加載到mysql的緩存中
CPU緩存:當代計算機最大的問題是 cpu性能提升了,但內存讀寫速度沒有跟上,所以為了適應當下的情況,增加了cpu的L1,L2,L3級的緩存
標準的操作方式就是查詢數據庫之前先查詢緩存
,如果緩存數據存在,則直接從緩存中返回,如果緩存數據不存在,再查詢數據庫,然后將數據存入redis
緩存更新是redis為了節約內存而設計出來的一個東西,主要是因為內存數據寶貴,當我們向redis插入太多數據,此時就可能會導致緩存中的數據過多,所以redis會對部分數據進行更新
,或者把他叫為淘汰更合適。
內存淘汰:redis自動進行,當redis內存達到咱們設定的max-memery的時候,會自動觸發淘汰機制
,淘汰掉一些不重要的數據(可以自己設置策略方式)
超時剔除:當我們給redis設置了過期時間ttl之后,redis會將超時的數據進行刪除,方便咱們繼續使用緩存
主動更新:我們可以手動調用方法把緩存刪掉,通常用于解決緩存和數據庫不一致問題
由于我們的緩存的數據源來自于數據庫
,而數據庫的數據是會發生變化的
,因此,如果當數據庫中數據發生變化,而緩存卻沒有同步
,此時就會有一致性問題存在
,其后果是:
用戶使用緩存中的過時數據,就會產生類似多線程數據安全問題,從而影響業務,產品口碑等;怎么解決呢?有如下幾種方案
Cache Aside Pattern 人工編碼方式:緩存調用者在更新完數據庫后再去更新緩存,也稱之為雙寫方案(一般采用
)
Read/Write Through Pattern : 由系統本身完成,數據庫與緩存的問題交由系統本身去處理
Write Behind Caching Pattern :調用者只操作緩存,其他線程去異步處理數據庫,實現最終一致
綜合考慮使用方案一,但是方案一調用者如何處理呢?這里有幾個問題
操作緩存和數據庫時有三個問題需要考慮:
如果采用第一個方案,那么假設我們每次操作數據庫后,都操作緩存,但是中間如果沒有人查詢,那么這個更新動作實際上只有最后一次生效,中間的更新動作意義并不大,我們可以把緩存刪除,等待再次查詢時,將緩存中的數據加載出來
刪除緩存還是更新緩存?
更新緩存:每次更新數據庫都更新緩存,無效寫操作較多
刪除緩存:更新數據庫時讓緩存失效,查詢時再更新緩存
如何保證緩存與數據庫的操作的同時成功或失敗?
單體系統,將緩存與數據庫操作放在一個事務
分布式系統,利用TCC等分布式事務方案
應該具體操作緩存還是操作數據庫,我們應當是先操作數據庫,再刪除緩存
,原因在于,如果你選擇第一種方案,在兩個線程并發來訪問時,假設線程1先來,他先把緩存刪了,此時線程2過來,他查詢緩存數據并不存在,此時他寫入緩存,當他寫入緩存后,線程1再執行更新動作時,實際上寫入的就是舊的數據,新的數據被舊數據覆蓋了。
先操作緩存還是先操作數據庫?
先刪除緩存,再操作數據庫(存在線程安全問題
)
先操作數據庫,再刪除緩存
緩存穿透 :緩存穿透是指客戶端請求的數據在緩存中和數據庫中都不存在,這樣緩存永遠不會生效,這些請求都會打到數據庫。
常見的解決方案有兩種:
緩存空對象
優點:實現簡單,維護方便
缺點:
額外的內存消耗
可能造成短期的不一致
布隆過濾
優點:內存占用較少,沒有多余key
缺點:
實現復雜
存在誤判可能
緩存空對象思路分析:當我們客戶端訪問不存在的數據時,先請求redis,但是此時redis中沒有數據,此時會訪問到數據庫,但是數據庫中也沒有數據,這個數據穿透了緩存,直擊數據庫,我們都知道數據庫能夠承載的并發不如redis這么高,如果大量的請求同時過來訪問這種不存在的數據,這些請求就都會訪問到數據庫,簡單的解決方案就是哪怕這個數據在數據庫中也不存在,我們也把這個數據存入到redis中去,這樣,下次用戶過來訪問這個不存在的數據,那么在redis中也能找到這個數據就不會進入到緩存了.
布隆過濾:布隆過濾器其實采用的是哈希思想來解決這個問題,通過一個龐大的二進制數組,走哈希思想去判斷當前這個要查詢的這個數據是否存在,如果布隆過濾器判斷存在,則放行,這個請求會去訪問redis,哪怕此時redis中的數據過期了,但是數據庫中一定存在這個數據,在數據庫中查詢出來這個數據后,再將其放入到redis中
假設布隆過濾器判斷這個數據不存在,則直接返回
這種方式優點在于節約內存空間,存在誤判,誤判原因在于:布隆過濾器走的是哈希思想,只要哈希思想,就可能存在哈希沖突
小總結:
緩存穿透產生的原因是什么?
用戶請求的數據在緩存中和數據庫中都不存在,不斷發起這樣的請求,給數據庫帶來巨大壓力
緩存穿透的解決方案有哪些?
緩存null值
布隆過濾
增強id的復雜度,避免被猜測id規律
做好數據的基礎格式校驗
加強用戶權限校驗
做好熱點參數的限流
此工具類已經對緩存穿透,和緩存擊穿實現了通用功能。
可以對比上敘的流程圖查閱
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實現常用功能”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。