聊聊redis實際運用及騷操作
聊起 redis 咱們大部分後端猿應該都不陌生，或多或少都用過。甚至大部分前端猿都知道。
資料結構： string、 hash、 list、 set (無序集合)、 setsorted(有序集合)，
運維方面 ： 持久化，主從複製，叢集，故障恢復 ，
園子裡已經由大佬科普過了，官方文件也能查到， 這裡就不細說 redis的“發展起家史”。
咱們今天就聊聊redis的快取應用場景（不推薦用redis做分散式鎖），redis常見操作(擊穿，雪崩，快取資料量過大等)，常見問題及處理方式。怎麼用到咱們專案中，提升產品體驗。結合我實際專案來解釋這裡面得思路。（saas,企業級應用）
型別 公共快取
資料極少變動：可使用本機記憶體快取，單例模式。(如預製分類、城市、配置，首頁佈局等)
資料會有變動：載入慢，但是使用者經常點選的資料，可使用分散式快取。(如熱點資料，評論，專案工作討論)
使用者相關快取
跟登陸賬戶相關，叢集化部署需要使用分散式快取
使用者登陸後的首屏資料，如，常用統計，分類許可權選單，待辦事項，工作臺等
延遲載入：有請求才做快取，無請求則不進行快取（動態資料）
穿透
大量無效的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/歡迎各位轉載，但是未經作者本人同意，轉載文章之後必須在文章頁面明顯位置給出作者和原文連線，否則保留追究法律責任的權利。