??各位小伙伴們大家好，歡迎來到這個小扎扎的Redis 6專欄，在這個系列專欄中我對B站黑馬的Redis教程進行一個總結，鑒于 看到就是學到、學到就是賺到 精神，這波依然是血賺 ┗|｀O′|┛

💡Redis知識點速覽

---

• 🍖 Redis緩存中間件
• • 🥩 緩存是什么
  • 🥩 Redis緩存已查詢數據
  • 🥩 redis緩存中間件實踐
• 🍖 緩存更新
• • 🥩 緩存更新的三個策略
  • 🥩 主動更新策略的三種方案
  • 🥩 主動更新的代碼實現

🍖 Redis緩存中間件

🥩 緩存是什么

??所謂緩存就是數據交換的緩沖區(稱作Cache [ k?? ] )，是一個臨時存貯數據的地方，一般讀寫性能較高。CPU的運算速度要遠遠大于內存的讀寫速度，這樣會使CPU花費很長時間等待數據從內存的獲取或者寫入，因此緩存的出現主要就是為了解決CPU運算速度與內存讀寫速度不匹配的矛盾
??說了半天緩存和web開發有什么必要的聯系嘛？當然有，在整個web開發的各個階段都可以使用到不同緩存，比如瀏覽器緩存頁面等靜態資源，tomcat服務器應用層緩存查詢過的數據，數據庫緩存索引信息等緩存的優點

• 降低后端負載
• 提高讀寫效率，降低響應時間

緩存的缺點

• 數據更新前后緩存區中該數據的一致性難保證
• 解決數據一致性需要復雜的業務代碼，提高后續維護成本
• 集群模式下提高運維成本

🥩 Redis緩存已查詢數據

??在未使用緩存之前，用戶的所有請求都會直接訪問數據庫，但是使用redis作為緩存之后就不一樣了。用戶的請求會是先在redis中查找，如果查到也就是命中的話就直接返回客戶端，如果未命中的話就去數據庫中查找，查到有結果就將查詢到的結果寫入redis中，然后返回給客戶端；未查到結果就返回404狀態碼

🥩 redis緩存中間件實踐

??黑馬點評中有這么一個業務：點擊商鋪圖片會通過id查詢該商鋪的相關信息，如果使用redis緩存的話，后期再訪問該商鋪的話就會直接到redis中查詢，可以大大縮短查詢所需時間

collector中定義與前端交互的方法，前端請求/shop-type/list?id=xx

@RestController
@RequestMapping("/shop")
public class ShopController {@Resourcepublic IShopService shopService;/*** 根據id查詢商鋪信息* @param id 商鋪id* @return 商鋪詳情數據*/@GetMapping("/{id}")public Result queryShopById(@PathVariable("id") Long id) {return shopService.queryById(id);}
}

編寫typeService里業務邏輯方法getList的接口和實現類，邏輯參考Redis緩存已查詢數據的相關分析

@Service
public class ShopServiceImpl extends ServiceImpl<ShopMapper, Shop> implements IShopService {@Autowiredprivate StringRedisTemplate stringRedisTemplate;@Overridepublic Result queryById(Long id) {// 從redis查詢商鋪緩存String shopJson = stringRedisTemplate.opsForValue().get(RedisConstants.CACHE_SHOP_KEY + id);// 判斷該商鋪是否存在if (StrUtil.isNotBlank(shopJson)) {// 存在直接返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return Result.ok(shop);}// 不存在查詢數據庫Shop shop = getById(id);if (shop == null) {// 數據庫中不存在直接返回錯誤信息return Result.fail("店鋪不存在");}// 數據庫中存在寫入redisstringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop));// 返回return Result.ok(shop);}
}

??經實驗驗證得知，使用redis緩存未命中時查詢耗時將近200毫秒，后續查詢命中之后只需幾毫秒，可見redis作為緩存中間件對數據讀取的功效還是很高的

🍖 緩存更新

??之前介紹redis的時候介紹過redis緩存的一些缺點，比如數據庫中數據更新前后緩存區中該數據的一致性難保證，該怎么應對redis緩存的這個缺點呢？這就引出接下來的學習內容——緩存更新策略

🥩 緩存更新的三個策略

??內存淘汰： redis底層的內存淘汰機制，無需我們自己維護，當內存不足時自動淘汰部分數據，下次查詢時更新緩存。這種機制的優點是維護成本極低，但是缺點也很明顯，由于淘汰數據的不確定性導致很難保證數據的一致性
??超時剔除： 向redis中添加緩存數據的時候設置TTL時間，到期后自動刪除緩存，下次查詢時更新緩存。這種機制維護成本不是很高，但是數據一致性同樣無法做到很高的保證，因為設置之后數據的有效期就固定了，但是更新時間不固定，若是數據在超時剔除之前發生更新然后查詢，得到的仍是更新之前的數據
??主動更新： 使用代碼在修改數據庫的同時更新緩存。這種策略能夠保證很高的數據一致性，但是伴隨而來的就是更高的維護成本，要在每一個更改語句后面加上redis緩存更新

??具體使用哪種策略取決于該業務對數據一致性的需求：一致性需求不高的話，可以使用內存淘汰策略。一致性需求較高的話，可以使用主動更新加上超時剔除策略，保證了較高的一致性
?

🥩 主動更新策略的三種方案

??代碼(Cache Aside Pattern)：最直接的一種方案，使用代碼在修改數據庫的同時更新緩存
??服務(Read/Warite Through Pattern)：將redis緩存與數據庫整合為一個服務，由這個服務來維護數據的一致性，在更新數據庫時只需要調用該服務即可，無需關心服務底層的業務邏輯，類似于封裝。但是市面上沒有現成的服務可以使用，自己封裝這么一個服務也很復雜，所以說這種方案可用性很差
??寫回(Write Behind Caching Pattern)：所有數據庫的CRUD操作都在redis緩存中完成，由另外一個獨立的線程異步的將緩存中的數據持久化到數據庫中，以此來保證數據的最終一致。這種方案有個很大的好處，那就是極大地減少了對數據庫的操作，如果主線程在另一個線程兩次持久化之間對redis中的數據操作多次，數據庫中只會執行最后一次操作，而不是也操作多次。但是也有壞處，那就是如果還沒等到另一個線程持久化數據庫，此時redis緩存發生宕機，緩存大多數在內存中，此時發生宕機就會導致緩存中的數據消失，數據庫中的數據就與宕機前redis中的數據不一致

??綜上所述，雖然Cache Aside Pattern方案是最復雜的一個，但是他也同樣是最可靠的一個，于是我們選擇它來進行接下來的代碼學習

主動更新策略注意項
??數據庫發生更新的時候直接刪除緩存中的該數據，而不是跟著更新緩存，因為如果發生連續修改多次的情況，更新緩存的話更新次數等于數據庫的更新次數；如果是刪除緩存數據的話就只需要刪除一次，下一次查詢直接從數據庫中查詢再寫入緩存。
??刪除緩存數據和數據庫操作應該保證原子性，也就是說刪除緩存數據操作和數據庫操作應該同時成功或者同時失敗，那么該如何實現呢？單體式系統中，可以通過將兩個操作放在一個事務中來完成；分布式系統中可以利用TCC等分布式事務方案來實現
??刪除緩存數據操作和數據庫操作的先后順序是什么？ 應該是先寫數據庫再刪除緩存，原因是這種方式發生線程安全性問題的可能較小

🥩 主動更新的代碼實現

controller層前端交互

/*** 更新商鋪信息* @param shop 商鋪數據* @return 無*/
@PutMapping
public Result updateShop(@RequestBody Shop shop) {// 寫入數據庫return shopService.update(shop);
}

??需要server的update方法，創建接口和實現類完成業務邏輯代碼編寫。主動更新＋超時剔除的策略就只有兩步，那就是在寫緩存的時候設置超時時間，更新數據庫之后刪除緩存

// 數據庫中存在寫入redis的時候設置超時時間
stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);/*** 更新商鋪信息* @param shop  商鋪信息* @return 前端返回數據*/
@Override
@Transactional
public Result update(Shop shop) {if (shop.getId() == null) {return Result.fail("店鋪id不能為空");}// 更新數據庫updateById(shop);// 刪除緩存stringRedisTemplate.delete(RedisConstants.CACHE_SHOP_KEY + shop.getId());// 返回return Result.ok();
}