利用Redis進(jìn)行數(shù)據(jù)緩存的項(xiàng)目實(shí)踐
1. 引言
緩存有啥用?
- 降低對(duì)數(shù)據(jù)庫的請(qǐng)求,減輕服務(wù)器壓力
- 提高了讀寫效率
緩存有啥缺點(diǎn)?
- 如何保證數(shù)據(jù)庫與緩存的數(shù)據(jù)一致性問題?
- 維護(hù)緩存代碼
- 搭建緩存一般是以集群的形式進(jìn)行搭建,需要運(yùn)維的成本
2. 將信息添加到緩存的業(yè)務(wù)流程
上圖可以清晰的了解Redis在項(xiàng)目中所處的位置,是數(shù)據(jù)庫與客戶端之間的一個(gè)中間件,也是數(shù)據(jù)庫的保護(hù)傘。有了Redis可以幫助數(shù)據(jù)庫進(jìn)行請(qǐng)求的阻擋,阻止請(qǐng)求直接打入數(shù)據(jù)庫,提高響應(yīng)速率,極大的提升了系統(tǒng)的穩(wěn)定性。
3. 實(shí)現(xiàn)代碼
下面將根據(jù)查詢商鋪信息來作為背景進(jìn)行代碼書寫,具體的流程圖如上所示。
3.1 代碼實(shí)現(xiàn)(信息添加到緩存中)
public static final String SHOPCACHEPREFIX = "cache:shop:"; @Autowired private StringRedisTemplate stringRedisTemplate; // JSON工具 ObjectMapper objectMapper = new ObjectMapper(); @Override public Result queryById(Long id) { //從Redis查詢商鋪緩存 String cacheShop = stringRedisTemplate.opsForValue().get(SHOPCACHEPREFIX + id); //判斷緩存中數(shù)據(jù)是否存在 if (!StringUtil.isNullOrEmpty(cacheShop)) { //緩存中存在則直接返回 try { // 將子字符串轉(zhuǎn)換為對(duì)象 Shop shop = objectMapper.readValue(cacheShop, Shop.class); return Result.ok(shop); } catch (JsonProcessingException e) { e.printStackTrace(); } } //緩存中不存在,則從數(shù)據(jù)庫里進(jìn)行數(shù)據(jù)查詢 Shop shop = getById(id); //數(shù)據(jù)庫里不存在,返回404 if (null==shop){ return Result.fail("信息不存在"); } //數(shù)據(jù)庫里存在,則將信息寫入Redis try { String shopJSon = objectMapper.writeValueAsString(shop); stringRedisTemplate.opsForValue().set(SHOPCACHEPREFIX+id,shopJSon,30,TimeUnit.MINUTES); } catch (JsonProcessingException e) { e.printStackTrace(); } //返回 return Result.ok(shop); }
3.2 緩存更新策略
數(shù)據(jù)庫與緩存數(shù)據(jù)一致性問題,當(dāng)數(shù)據(jù)庫信息修改后,緩存的信息應(yīng)該如何處理?
內(nèi)存淘汰 | 超時(shí)剔除 | 主動(dòng)更新 | |
---|---|---|---|
說明 | 不需要自己進(jìn)行維護(hù),利用Redis的淘汰機(jī)制進(jìn)行數(shù)據(jù)淘汰 | 給緩存數(shù)據(jù)添加TTL | 編寫業(yè)務(wù)邏輯,在修改數(shù)據(jù)庫的同時(shí)更新緩存 |
一致性 | 差勁 | 一般 | 好 |
維護(hù)成本 | 無 | 低 | 高 |
這里其實(shí)是需要根據(jù)業(yè)務(wù)場(chǎng)景來進(jìn)行選擇
- 高一致性:選主動(dòng)更新
- 低一致性:內(nèi)存淘汰和超時(shí)剔除
3.3 實(shí)現(xiàn)主動(dòng)更新
此時(shí)需要實(shí)現(xiàn)數(shù)據(jù)庫與緩存一致性問題,在這個(gè)問題之中還有多個(gè)問題值得深思
刪除緩存還是更新緩存?
當(dāng)數(shù)據(jù)庫發(fā)生變化時(shí),我們?nèi)绾翁幚砭彺嬷袩o效的數(shù)據(jù),是刪除它還是更新它?
更新緩存:每次更新數(shù)據(jù)庫都更新緩存,無效寫操作較多
刪除緩存:更新數(shù)據(jù)庫時(shí)刪除緩存,查詢時(shí)再添加緩存
由此可見,選擇刪除緩存是高效的。
如何保證緩存與數(shù)據(jù)庫的操作的同時(shí)成功或失?。?/strong>
單體架構(gòu):單體架構(gòu)中采用事務(wù)解決
分布式架構(gòu):利用分布式方案進(jìn)行解決
先刪除緩存還是先操作數(shù)據(jù)庫?
在并發(fā)情況下,上述情況是極大可能會(huì)發(fā)生的,這樣子會(huì)導(dǎo)致緩存與數(shù)據(jù)庫數(shù)據(jù)庫不一致。
先操作數(shù)據(jù)庫,在操作緩存這種情況,在緩存數(shù)據(jù)TTL剛好過期時(shí),出現(xiàn)一個(gè)A線程查詢緩存,由于緩存中沒有數(shù)據(jù),則向數(shù)據(jù)庫中查詢,在這期間內(nèi)有另一個(gè)B線程進(jìn)行數(shù)據(jù)庫更新操作和刪除緩存操作,當(dāng)B的操作在A的兩個(gè)操作間完成時(shí),也會(huì)導(dǎo)致數(shù)據(jù)庫與緩存數(shù)據(jù)不一致問題。
完蛋?。?!兩種方案都會(huì)造成數(shù)據(jù)庫與緩存一致性問題的發(fā)生,那么應(yīng)該如何來進(jìn)行選擇呢?
雖然兩者方案都會(huì)造成問題的發(fā)生,但是概率上來說還是先操作數(shù)據(jù)庫,再刪除緩存發(fā)生問題的概率低一些,所以可以選擇先操作數(shù)據(jù)庫,再刪除緩存的方案。
個(gè)人見解:
如果說我們?cè)谙炔僮鲾?shù)據(jù)庫,再刪除緩存方案中線程B刪除緩存時(shí),我們利用java來刪除緩存會(huì)有Boolean返回值,如果是false,則說明緩存已經(jīng)不存在了,緩存不存在了,則會(huì)出現(xiàn)上圖的情況,那么我們是否可以根據(jù)刪除緩存的Boolean值來進(jìn)行判斷是否需要線程B來進(jìn)行緩存的添加(因?yàn)橹笆切枰樵兊木€程來添加緩存,這里考慮線程B來添加緩存,線程B是操作數(shù)據(jù)庫的緩存),如果線程B的添加也在線程A的寫入緩存之前完成也會(huì)造成數(shù)據(jù)庫與緩存的一致性問題發(fā)生。那么是否可以延時(shí)一段時(shí)間(例如5s,10s)再進(jìn)行數(shù)據(jù)的添加,這樣子雖然最終會(huì)統(tǒng)一數(shù)據(jù)庫與緩存的一致性,但是若是在這5s,10s內(nèi)又有線程C,D等等來進(jìn)行緩存的訪問呢?C,D線程的訪問還是訪問到了無效的緩存信息。
所以在數(shù)據(jù)庫與緩存的一致性問題上,除非在寫入正確緩存之前拒絕相關(guān)請(qǐng)求進(jìn)行服務(wù)器來進(jìn)行訪問才能避免用戶訪問到錯(cuò)誤信息,但是拒絕請(qǐng)求對(duì)用戶來說是致命的,極大可能會(huì)導(dǎo)致用戶直接放棄使用應(yīng)用,所以我們只能盡可能的減少問題可能性的發(fā)生。(個(gè)人理解,有問題可以在評(píng)論區(qū)留言賜教)
@Override @Transactional public Result updateShop(Shop shop) { Long id = shop.getId(); if (null==id){ return Result.fail("店鋪id不能為空"); } //更新數(shù)據(jù)庫 boolean b = updateById(shop); //刪除緩存 stringRedisTemplate.delete(SHOPCACHEPREFIX+shop.getId()); return Result.ok(); }
4. 緩存穿透
緩存穿透是指客戶端請(qǐng)求的數(shù)據(jù)在緩存中和數(shù)據(jù)庫中都不存在,這樣緩存永遠(yuǎn)不會(huì)生效,這些請(qǐng)求都會(huì)打到數(shù)據(jù)庫。
解決方案:
緩存空對(duì)象
缺點(diǎn):
- 空間浪費(fèi)
- 如果緩存了空對(duì)象,在空對(duì)象的有效期內(nèi),我們后臺(tái)在數(shù)據(jù)庫新增了和空對(duì)象相同id的數(shù)據(jù),這樣子就會(huì)造成數(shù)據(jù)庫與緩存一致性問題
布隆過濾器
優(yōu)點(diǎn):
內(nèi)存占用少
缺點(diǎn):
- 實(shí)現(xiàn)復(fù)雜
- 存在誤判的可能(存在的數(shù)據(jù)一定會(huì)判斷成功,但是不存在的數(shù)據(jù)也有可能會(huì)放行進(jìn)來,有幾率造成緩存穿透)
4.1 解決緩存穿透(使用空對(duì)象進(jìn)行解決)
public static final String SHOPCACHEPREFIX = "cache:shop:"; @Autowired private StringRedisTemplate stringRedisTemplate; // JSON工具 ObjectMapper objectMapper = new ObjectMapper(); @Override public Result queryById(Long id) { //從Redis查詢商鋪緩存 String cacheShop = stringRedisTemplate.opsForValue().get(SHOPCACHEPREFIX + id); //判斷緩存中數(shù)據(jù)是否存在 if (!StringUtil.isNullOrEmpty(cacheShop)) { //緩存中存在則直接返回 try { // 將子字符串轉(zhuǎn)換為對(duì)象 Shop shop = objectMapper.readValue(cacheShop, Shop.class); return Result.ok(shop); } catch (JsonProcessingException e) { e.printStackTrace(); } } // 因?yàn)樯厦媾袛嗔薱acheShop是否為空,如果進(jìn)到這個(gè)方法里面則一定是空,直接過濾,不打到數(shù)據(jù)庫 if (null != cacheShop){ return Result.fail("信息不存在"); } //緩存中不存在,則從數(shù)據(jù)庫里進(jìn)行數(shù)據(jù)查詢 Shop shop = getById(id); //數(shù)據(jù)庫里不存在,返回404 if (null==shop){ // 緩存空對(duì)象 stringRedisTemplate.opsForValue().set(SHOPCACHEPREFIX+id,"",2,TimeUnit.MINUTES); return Result.fail("信息不存在"); } //數(shù)據(jù)庫里存在,則將信息寫入Redis try { String shopJSon = objectMapper.writeValueAsString(shop); stringRedisTemplate.opsForValue().set(SHOPCACHEPREFIX+id,shopJSon,30,TimeUnit.MINUTES); } catch (JsonProcessingException e) { e.printStackTrace(); } //返回 return Result.ok(shop); }
上述方案終究是被動(dòng)方案,我們可以采取一些主動(dòng)方案,例如
- 給id加復(fù)雜度
- 權(quán)限
- 熱點(diǎn)參數(shù)的限流
5. 緩存雪崩
緩存雪崩是指在同一時(shí)段大量的緩存key同時(shí)失效或者Redis服務(wù)宕機(jī),導(dǎo)致大量請(qǐng)求到達(dá)數(shù)據(jù)庫,帶來巨大壓力。
解決方案:
- 給不同的Key的TTL添加隨機(jī)值
大量的Key同時(shí)失效,極大可能是TTL相同,我們可以隨機(jī)給TTL - 利用Redis集群提高服務(wù)的可用性
- 給緩存業(yè)務(wù)添加降級(jí)限流策略
- 給業(yè)務(wù)添加多級(jí)緩存
6. 緩存擊穿
緩存擊穿問題也叫熱點(diǎn)Key問題,就是一個(gè)被高并發(fā)訪問并且緩存重建業(yè)務(wù)較復(fù)雜的key突然失效了,無數(shù)的請(qǐng)求訪問會(huì)在瞬間給數(shù)據(jù)庫帶來巨大的沖擊。
常見的解決方案:
- 互斥鎖
- 邏輯過期
互斥鎖:
即采用鎖的方式來保證只有一個(gè)線程去重建緩存數(shù)據(jù),其余拿不到鎖的線程休眠一段時(shí)間再重新重頭去執(zhí)行查詢緩存的步驟
優(yōu)點(diǎn):
- 沒有額外的內(nèi)存消耗(針對(duì)下面的邏輯過期方案)
- 保證了一致性
缺點(diǎn):
- 線程需要等待,性能受到了影響
- 可能會(huì)產(chǎn)生死鎖
邏輯過期:
邏輯過期是在緩存數(shù)據(jù)中額外添加一個(gè)屬性,這個(gè)屬性就是邏輯過期的屬性,為什么要使用這個(gè)來判斷是否過期而不使用TTL呢?因?yàn)槭褂肨TL的話,一旦過期,就獲取不到緩存中的數(shù)據(jù)了,沒有拿到鎖的線程就沒有舊的數(shù)據(jù)可以返回。
它與互斥鎖最大的區(qū)別就是沒有線程的等待了,誰先獲取到鎖就去重建緩存,其余線程沒有獲取到鎖就返回舊數(shù)據(jù),不去做休眠,輪詢?nèi)カ@取鎖。
重建緩存會(huì)新開一個(gè)線程去執(zhí)行重建緩存,目的是減少搶到鎖的線程的響應(yīng)時(shí)間。
優(yōu)點(diǎn):
線程無需等待,性能好
缺點(diǎn):
- 不能保證一致性
- 緩存中有額外的內(nèi)存消耗
- 實(shí)現(xiàn)復(fù)雜
兩個(gè)方案各有優(yōu)缺點(diǎn):一個(gè)保證了一致性,一個(gè)保證了可用性,選擇與否主要看業(yè)務(wù)的需求是什么,側(cè)重于可用性還是一致性。
6.1 互斥鎖代碼
互斥鎖的鎖用什么?
使用Redis命令的setnx命令。
首先實(shí)現(xiàn)獲取鎖和釋放鎖的代碼
/** * 嘗試獲取鎖 * * @param key * @return */ private boolean tryLock(String key) { Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS); return BooleanUtil.isTrue(flag); } /** * 刪除鎖 * * @param key */ private void unLock(String key) { stringRedisTemplate.delete(key); }
代碼實(shí)現(xiàn)
public Shop queryWithMutex(Long id) throws InterruptedException { //從Redis查詢商鋪緩存 String cacheShop = stringRedisTemplate.opsForValue().get(SHOPCACHEPREFIX + id); //判斷緩存中數(shù)據(jù)是否存在 if (!StringUtil.isNullOrEmpty(cacheShop)) { //緩存中存在則直接返回 try { // 將子字符串轉(zhuǎn)換為對(duì)象 Shop shop = objectMapper.readValue(cacheShop, Shop.class); return shop; } catch (JsonProcessingException e) { e.printStackTrace(); } } // 因?yàn)樯厦媾袛嗔薱acheShop是否為空,如果進(jìn)到這個(gè)方法里面則一定是空,直接過濾,不打到數(shù)據(jù)庫 if (null != cacheShop) { return null; } Shop shop = new Shop(); // 緩存擊穿,獲取鎖 String lockKey = "lock:shop:" + id; try{ boolean b = tryLock(lockKey); if (!b) { // 獲取鎖失敗了 Thread.sleep(50); return queryWithMutex(id); } //緩存中不存在,則從數(shù)據(jù)庫里進(jìn)行數(shù)據(jù)查詢 shop = getById(id); //數(shù)據(jù)庫里不存在,返回404 if (null == shop) { // 緩存空對(duì)象 stringRedisTemplate.opsForValue().set(SHOPCACHEPREFIX + id, "", 2, TimeUnit.MINUTES); return null; } //數(shù)據(jù)庫里存在,則將信息寫入Redis try { String shopJSon = objectMapper.writeValueAsString(shop); stringRedisTemplate.opsForValue().set(SHOPCACHEPREFIX + id, shopJSon, 30, TimeUnit.MINUTES); } catch (JsonProcessingException e) { e.printStackTrace(); } }catch (Exception e){ }finally { // 釋放互斥鎖 unLock(lockKey); } //返回 return shop; }
6.2 邏輯過期實(shí)現(xiàn)
邏輯過期不設(shè)置TTL
代碼實(shí)現(xiàn)
@Data public class RedisData { private LocalDateTime expireTime; private Object data; }
由于是熱點(diǎn)key,所以key基本都是手動(dòng)導(dǎo)入到緩存,代碼如下
/** * 邏輯過期時(shí)間對(duì)象寫入緩存 * @param id * @param expireSeconds */ public void saveShopToRedis(Long id,Long expireSeconds){ // 查詢店鋪數(shù)據(jù) Shop shop = getById(id); // 封裝為邏輯過期 RedisData redisData = new RedisData(); redisData.setData(shop); redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds)); // 寫入Redis stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY+id, JSONUtil.toJsonStr(redisData)); }
邏輯過期代碼實(shí)現(xiàn)
/** * 緩存擊穿:邏輯過期解決 * @param id * @return * @throws InterruptedException */ public Shop queryWithPassLogicalExpire(Long id) throws InterruptedException { //1. 從Redis查詢商鋪緩存 String cacheShop = stringRedisTemplate.opsForValue().get(SHOPCACHEPREFIX + id); //2. 判斷緩存中數(shù)據(jù)是否存在 if (StringUtil.isNullOrEmpty(cacheShop)) { // 3. 不存在 return null; } // 4. 存在,判斷是否過期 RedisData redisData = JSONUtil.toBean(cacheShop, RedisData.class); JSONObject jsonObject = (JSONObject) redisData.getData(); Shop shop = JSONUtil.toBean(jsonObject, Shop.class); LocalDateTime expireTime = redisData.getExpireTime(); // 5. 判斷是否過期 if (expireTime.isAfter(LocalDateTime.now())){ // 5.1 未過期 return shop; } // 5.2 已過期 String lockKey = "lock:shop:"+id; boolean flag = tryLock(lockKey); if (flag){ // TODO 獲取鎖成功,開啟獨(dú)立線程,實(shí)現(xiàn)緩存重建,建議使用線程池去做 CACHE_REBUILD_EXECUTOR.submit(()->{ try { // 重建緩存 this.saveShopToRedis(id,1800L); }catch (Exception e){ }finally { // 釋放鎖 unLock(lockKey); } }); } // 獲取鎖失敗,返回過期的信息 return shop; } /** * 線程池 */ private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);
到此這篇關(guān)于利用Redis進(jìn)行數(shù)據(jù)緩存的項(xiàng)目實(shí)踐的文章就介紹到這了,更多相關(guān)Redis 數(shù)據(jù)緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
基于redis實(shí)現(xiàn)的點(diǎn)贊功能設(shè)計(jì)思路詳解
點(diǎn)贊是我們現(xiàn)在經(jīng)常見到的一個(gè)效果,如朋友圈、微博都有點(diǎn)贊的效果,下面這篇文章主要跟大家分享了基于redis實(shí)現(xiàn)的點(diǎn)贊功能設(shè)計(jì)思路的相關(guān)資料,文中介紹的非常詳細(xì),對(duì)大家實(shí)現(xiàn)點(diǎn)贊功能具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起看看吧。2017-05-05解決Redis報(bào)錯(cuò)MISCONF?Redis?is?configured?to?save?RDB?snap
這篇文章主要給大家介紹了關(guān)于如何解決Redis報(bào)錯(cuò)MISCONF?Redis?is?configured?to?save?RDB?snapshots的相關(guān)資料,文中通過代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-11-11Redis集群指定主從關(guān)系及動(dòng)態(tài)增刪節(jié)點(diǎn)方式
這篇文章主要介紹了Redis集群指定主從關(guān)系及動(dòng)態(tài)增刪節(jié)點(diǎn)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-01-01Redis數(shù)據(jù)持久化方式技術(shù)解析
Redis(Remote Dictionary Server ),即遠(yuǎn)程字典服務(wù),是一個(gè)開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫,并提供多種語言的API2021-09-09Redis Sentinel實(shí)現(xiàn)哨兵模式搭建小結(jié)
這篇文章主要介紹了Redis Sentinel實(shí)現(xiàn)哨兵模式搭建小結(jié),小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-12-12