redis的數據庫是存放在內存當中，所以對內存的監控至關重要
redis內存監控和解析
1.如何查看redis內存使用情況
[root@localhost utils]# redis-cli -h 20.0.0.170 -p 6379
20.0.0.170:6379> info memory
used_memory:853336 //redis中數據占用的內存
used_memory_rss:10473472 //redis向操作系統申請的內存
used_memory_peak:854312 //redis使用內存的峰值
作為一個運維工程師，每天的系統巡檢工作是必不可少的。（比如硬件巡檢，數據庫 nginx redis docker k8s ）
但是在redis內存方面，最重要的就是以上三點
2.內存碎片率
內存碎片率=Redis向操作系統申請的內存 / Redis中的數據占用的內存
mem_fragmentation_ratio = used_memory_rss / used_memory
mem_fragmentation_ratio：內存碎片率。
系統以及分配給了redis，但是redis未能夠有效利用的內存
[root@localhost ~]# redis-cli info memory | grep ratio
allocator_frag_ratio:1.29
//分配器碎片比例，redis主進程調度時產生的內存空間，越小越好
值越高，代表內存越高，內存的浪費就越多allocator_rss_ratio:5.99
分配器占用物理內存的比例，就算告訴大家主進程調度執行時占用了多少物理內存rss_overhead_ratio:1.22
rss是向系統申請的內存空間，表示redis占用物理內存額外的開銷比例，比例越低越好。redis實際占用的物理內存和向系統申請的內存越接近，額外的開銷越低mem_fragmentation_ratio:13.23
內存碎片的比例，越低越好，占用內存數值越低，表示內存使用率越高。
內存碎片產生的原因
- Redis內部有自已的內存管理器，為了提高內存使用的效率，來對內存的申請和釋放進行管理。
- Redis中的值刪除的時候，并沒有把內存直接釋放、交還給操作系統，而是交給了Redis內部有內存管理器。
- Redis中申請內存的時候，也是先看自己的內存管理器中是否有足夠的內存可用。
- Redis的這種機制，提高了內存的使用率，但是會使Redis中有部分自己沒在用，卻不釋放的內存，導致了內存碎片的發生。
?
如何自動清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
手動清理
[root@localhost ~]# redis-cli memory purge
OK
手動清理
內存使用率
redis實例的內存使用率超過可用最大內存，操作系統將開始進行內存與swap空間交換。
避免內存交換發生的方法：
- 針對緩存數據大小選擇安裝Redis 實例
- 盡可能的使用Hash數據結構存儲
- 設置key的過期時間
設置redis最大內存閥值
一旦到達閥值，自動清理碎片，開啟key的回收機制。
key的回收機制策略
vim /etc/redis/6379.conf
line 599maxmemory-policy volatile-lru
使用redis內置的LRU算法，把已經設置了過期時間的鍵值對中淘汰數據，移除最近最少使用鍵值對（針值對已經設置了過期時間的鍵值對）maxmemory-policy volatile-ttl
已經設置了過期時間的鍵值對，從當中挑選一個即將過期的鍵值對（針對有設置過期時間的鍵值對）maxmemory-policy volatile-random：
從已經設置了過期時間的鍵值對當中隨即淘汰一個鍵值對，挑選數據隨機淘汰鍵值對。（對設置了過期時間的鍵值對進行隨機移除。）allkeys-lru：
LRU算法當中，對所有的鍵值對進行淘汰，移除最少使用的鍵值對。（針對所有鍵值對）allkeys-random：
從所有鍵值對當中任意選擇選擇數據進行淘汰（無差別淘汰，不使用）maxmemory-policy noeviction
禁止鍵值對回收（不刪除任何鍵值對，直到redis把內存塞滿，寫不了，報錯）在工作中，一定要給redis 占用內存設置閥值 ！！！！
而且在實際工作中，盡量使用禁止鍵值對回收，或者使用將最少使用鍵值對刪除。
隨機刪除萬萬不可使用！！！！！
redis占用內存的效率問題如何解決
- 1.日常巡檢當中，對redis的占用情況做監控
- 2.設置redis占用系統內存的閥值，避免占用系統全部內存
- 3.內存碎片清理 手動，自動
- 4.配置一個合適的key回收機制
redis的雪崩，緩存擊穿，緩存穿透的原因和解決方案
redis的雪崩
大量的應用請求無法在redis 緩存當中處理，請求會全部發送到嗎后臺數據庫，數據庫本身并發能力本身就很差，一旦高并發數據庫會很快崩潰。
什么情況會導致雪崩？
- redis集群大面積故障
- redis緩存中，大量數據同時過期，大量請求無法得到處理
- redis實例宕機
解決方案
- 事前：高可用架構，方式整個緩存故障。主從復制和哨兵模式，redis集群
- 事中：在國內用的比較多的方式：HySTRIX，熔斷（到達閥值自動斷開），降級（到達閥值立刻降級），限流三個手段來降低雪崩發生之后的損失。
- 數據庫不死即可，慢可以，但不能沒有響應
- 事后：數據備份
redis的緩存擊穿
緩存擊穿主要是熱點數據緩存過期，或者被刪除，多個請求并發訪問熱點數據，請求也是轉發到數據庫了，導致數據庫的性能快速下降。
經常被請求的緩存數據，最好設置為永不過期。
鍵值對還在，但是值被替換，原有的請求找不到之后，同樣也回去請求后臺數據庫，也是擊穿的類型一種
redis的緩存穿透：
緩存中沒數據，數據庫中也沒有對應數據，但是有用戶一直在發起這個都沒有的請求，而且請求的數據格式很大。黑客在利用漏洞攻擊，壓垮應用數據庫。
