前言
聊起 redis 咱們大部分后端猿應該都不陌生，或多或少都用過。甚至大部分前端猿都知道。
數據結構： string、 hash、 list、 set (無序集合)、 setsorted(有序集合)，
運維方面 ： 持久化，主從復制，集群，故障恢復 ，
園子里已經由大佬科普過了，官方文檔也能查到， 這里就不細說 redis的“發展起家史”。
咱們今天就聊聊redis的緩存應用場景（不推薦用redis做分布式鎖），redis常見操作(擊穿，雪崩，緩存數據量過大等)，常見問題及處理方式。怎么用到咱們項目中，提升產品體驗。結合我實際項目來解釋這里面得思路。（saas,企業級應用）
類型
公共緩存
數據極少變動：可使用本機內存緩存，單例模式。(如預制分類、城市、配置，首頁布局等)
數據會有變動：加載慢，但是用戶經常點擊的數據，可使用分布式緩存。(如熱點數據，評論，項目工作討論)
用戶相關緩存
跟登陸賬戶相關，集群化部署需要使用分布式緩存
用戶登陸后的首屏數據，如，常用統計，分類權限菜單，待辦事項，工作台等
加載方式
預加載：系統初始化即加載數據進入緩存（比如相關靜態數據）
延遲加載：有請求才做緩存，無請求則不進行緩存（動態數據）
時間設置
不過期
固定過期時間（幾小時，哪一天）
非固定過期時間（做過期時間的更新，獲取redis數據時同步更新緩存時間， 如下流程圖示意）
失效帶來的問題
穿透
大量無效的Key訪問，數據並不存在
解決：Key做驗證過濾；無數據也進行緩存（空對象，非null）
擊穿
1個Key失效，但這個Key有大量並發請求，特別是公共緩存
解決：失效時間點設置在非高峰時間段；主動做緩存更新（過期之前操作），而不是清理在重建
雪崩
大量key設置了相似過期時間（前后幾分鍾），導致數據庫請求瞬間增加。或者緩存服務器掛了
解決：大量Key不要設置相同時間點過期或者過期時間比較接近，可以進行相對時間設置
項目使用思考
下面結合我自己項目，各位看官可酌情參考，騷操作開始
反向操作
緩存部分數據
有些數據太多，如果一直都是全部緩存，可能會帶來一些問題，內存會爆掉，我們可以緩存部分數據， 比如id（id和權限有關，通過權限去取鏈路太長，而權限的變更不頻繁）
讓實體無數據被緩存。數據可被緩存，但引起該緩存失效點眾多難以全部覆蓋
讓數據持續有效，提升緩存命中率
當Get數據有緩存之時，重置緩存有效時間
利用隊列、事件總線、發布訂閱、任務管理等進行異步緩存預處理
設置緩存版本時間，進行對比（適用於主從關系的數據）
什么意思呢，清理緩存的地方太多，無法覆蓋，我們可以設置版本緩存時間。讓相關緩存和這個緩存版本時間進行對比 屬性緩存時間> 緩存版本時間=有效
（舉個例子）一個項目下由多個工單, 工單設置了緩存，如果項目的基礎信息修改，沒法及時清理所有工單的緩存（其實這樣也不科學,可能導致連接數過高）可以為這個項目設置緩存的時間，獲取工單信息的時候如果工單的緩存的時間大於項目緩存的時間。有 效直接返回數據，如果無效，則獲取DB更新相關緩存即可
這反手一波波操作很騷，咱們說下正常操作（其實也不算騷，反過來思考）
正常操作
常用數據加入緩存
請求數量龐大的請求加入緩存
查詢較慢（通常是數據量基數龐大）的請求加入緩存
舉個例子，像下列基本都可以做緩存(根據自己的業務來，也可不做，一種方案)
首頁列表（或常用列表）
置頂內容標題
未讀計數(也可用消息隊列）
常用協作目標聯系人搜索
常用統計周視圖日程
首屏數據
統計
整體操作
數據完整的置入緩存
用戶信息
權限信息
緩存組
讓具備緩存失效關聯關系的可將關鍵置入緩存組，失效則同時進行失效，關系可存放於內存或者Redis支持結構里面
善用redis,合理利用二級緩存，合理利用Redis所支持的結構，以提升項目整體性能，redis雖好，不可”貪杯“，否則影響穩定性就得不償失了（redis只是一個方面，還可以分表，分庫，數據庫拆分，kafka，ElasticSearch，Solr等，技術都是手段，提供給用戶好的體驗,解決問題才是最重要的）
謝謝！
如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”將是我最大的寫作動力！
本文版權歸作者和博客園共有，來源網址：https://www.cnblogs.com/DanielYao/歡迎各位轉載，但是未經作者本人同意，轉載文章之后必須在文章頁面明顯位置給出作者和原文連接，否則保留追究法律責任的權利。
