8.redis-緩存的使用與設計

1.緩存的受益與成本
(1)受益
加速讀寫：經過緩存加速讀寫速度：CPU L1/L2/L3 Cache,Linux page Cache加速硬盤讀寫，瀏覽器換成，Ehcache緩存數據庫結果
下降後端負載：侯丹服務器經過前端緩存下降負載：業務端使用Redis下降後端mysql負載等
(2)成本
數據不一致：緩存層和數據層有時間窗口不一致，和更新策略有關
代碼維護成本：多了一層緩存邏輯
運維成本：例如Redis Cluster
(3)使用場景
下降後端負載：
-對高消耗的SQL：jojn結果集/分組統計結果緩存
加速請求響應
-利用Redis/Memcache優化IO響應時間
大量寫合併爲批量寫：
如計數器先RDBedis累加批量寫DB
2.緩存更新策略
(1)LRU/LFU/FIFO算法剔除：例如maxmemory-policy
一致性最差，維護成本底
(2)超時剔除:例如expire(設置過時時間)
一致性較差，維護成本底
(3)主動更新：開發控制生命週期
一致性強，維護成本高
(4)兩條建議
低一致性：最大內存和淘汰策略
高一致性：超時剔除和主動更新結合，最大內存和淘汰策略兜底
3.換成粒度控制三個角度
(1)通用性：全量屬性更好
(2)佔用空間；部分屬性更好
(3)代碼維護：表面上全量屬性更好
4.緩存穿透-大量請求不命中
(1)產生緣由：
業務代碼自身問題
惡意攻擊，爬蟲等
(2)如何發現問題
業務的響應時間
業務自己問題
相關指標：總調用數，緩存層命中數，存儲層命中數
(3)解決方式1-緩存空對象
若是在緩存層miss，在storage數據庫層也是miss,正常是直接返回給客戶端，解決方式直接把獲取不到的結果緩存到緩存層

兩個問題：
問題一:須要更多的鍵
問題二：緩存層和存儲層數據「短時間」不一致
(4)解決方式2-布隆過濾器攔截

5.無底洞問題
(1)關鍵點：
更多的機器！=更高的性能
批量接口需求(mget,mset等)
數據增加與水平擴展需求
(2)優化IO的幾種方法
命令自己優化：例如慢查詢keys,hgetall bigkey
減小網絡通訊次數
下降接入成本：例如客戶端長鏈接/鏈接池，NIO等
(4)四種批量優化的方法
串行mget
串行IO
並行IO
hash_tag
6.熱點key重建優化
(1)問題描述：熱點key+大量的線程作重建時間

 

(2)三個目標
目標1：減小重緩存的次數
目標2：數據儘量一致
目標3：減小潛在危險
(3)兩個解決方式
第一：互斥鎖(mutex key)
互斥鎖流程:第一個獲取緩存須要重建的線程若是發現了到了重建的時候，把重建查詢數據庫加上一把鎖，當在這個時間段完成這個工做後，打開鎖。當在這個過程當中有其它線程獲取緩存，發現重建的過程被鎖住了，由於只有一個線程能夠作這個事情，而後等在輸出,只有發現鎖解開的時候，就能夠直接獲取到緩存

優勢：思路簡單，保證一致性
缺點：代碼複雜度增長，存在死鎖的風險
第二：永遠不過時
緩存層面：沒有設置過時時間(沒有用expire)
功能層面：爲每一個value添加邏輯過時時間，但發現超過邏輯過時時間後，會使用單獨的線程去構建緩存
優勢：基本杜絕熱點key重建問題
缺點：不保證一致性，邏輯過時時間增長維成本和內存成本