一、redis的性能管理

1、內存指標info memory

內存指標（重要）
used_memory:853736	數據占用的內存
used_memory_rss:10551296	redis向操作系統申請的內存
used_memory_peak:853736	redis使用內存的峰值
注：單位：字節

系統巡檢：硬件巡檢、數據庫、中間件（nginx、redis）、docker、k8s

2、內存碎片率

（1）定義：系統已分配給redis，但reids未能有效利用的內存

（2）計算格式：內存碎片率=used_memory_rss/used_memory

（3）監控指標redis-cli info memory|grep ratio（生產環境常用）

監控指標		定義
allocator_frag_ratio:1.29	分配器碎片的比例 （越小越好，值越高，內存浪費越多）	redis主進程調度時產生的內存
allocator_rss_ratio:5.49	分配器占用物理內存的比例	主進程調度時占用的物理內存
rss_overhead_ratio:1.38	redis占用物理空間額外的開銷比例（比例越低越好，redis實際占用的物理內存和向系統申請的內存越接近，額外的開銷越低）	RSS是redis向系統申請的內存空間
mem_fragmentation_ratio:15.59	內存碎片率 （越低越好，內存使用率越高）

3、清理內存的兩種方式

（1）自動清理碎片vim /etc/redis/6379.conf

末尾添加activedefrag yes自動清理碎片的配置

（2）手動清理碎片redis-cli memory purge

4、設置redis的最大內存閥值

（在工作中一定要設置redis的占用內存閾值。若不設置閾值，會塞滿內存，直到炸）

（1）先設置最大內存閥值vim /etc/redis/6379.conf

添加maxmemory 1gb

一旦達到閥值，會自動清理碎片，開啟key的回收機制

（2）再開啟key的回收機制

key的回收機制
maxmemory-policy volatile-lru （常用）	使用redis內置的lru算法，在已設置過期時間的鍵值對中淘汰數據中，移除最近最少使用的鍵值對
maxmemory-policy volatile-ttl （常用）	使用redis內置的ttl算法，在已設置過期時間的鍵值對中挑選一個即將過期的鍵值對
maxmemory-policy volatile-random （少用）	在已設置過期時間的鍵值對中，挑選數據，隨機淘汰鍵值對
注：以上算法只針對已設置過期時間的鍵值對，永不過期的不在此范圍內
allkeys-lru	使用redis內置的lru算法，對所有的鍵值對進行淘汰，移除最少使用的鍵值對
allkeys-random （更少用）	在所有鍵值對中任意選擇數據進行淘汰
注：以上算法針對所有的鍵值對，無論是否設置過期時間
maxmemory-policy noeviction （最常用）	禁止鍵值對回收（不刪除任何鍵值對，直到redis把內存塞滿，寫滿報錯為止）

【面試題】redis占用內存的效率問題如何解決？（經驗）

①日常巡檢中，監控redis的占用情況

②設置redis占用系統內存的閥值，避免占用系統全部內存

③手動/自動清理內存碎片

④配置合適的key回收機制

5、redis雪崩（緩存雪崩）（少見）

（1）定義

大量的應用請求無法在redis緩存中處理，請求會全部發送到后臺數據庫，數據庫并發能力本身就差，一旦高并發，數據庫很快會崩潰

（2）產生雪崩的原因

①redis集群大面積故障

②在redis緩存中，大量數據同時過期，大量的請求無法得到處理

③redis實例宕機

（3）解決雪崩的方式

①事前預防：采用高可用架構（主從復制、哨兵模式、redis集群），防止整個緩存故障

②事中處理（開發）：在國內通用方式——HySTRIX（熔斷、降級、限流），降低雪崩發生后的損失，確保數據庫不死，可以慢，但不能沒有響應

③事后解決：以redis備份的方式恢復數據（運維）或快速緩存預熱（開發）

6、redis的緩存擊穿（重點）

（1）產生原因

①熱點數據緩存過期或被刪除，當多個請求并發訪問熱點數據時，請求轉發到數據庫，導致數據庫性能快速下降。經常被請求的緩存數據最好設置為永不過期

②鍵值對還在，但值被替換，原有的請求找不到之后，同樣會請求后臺數據庫，導致數據庫性能快速下降

（2）解決方式

①熱點數據設置成永不過期

②恢復原有的值

7、redis的緩存穿透（惡意攻擊）（很少見）

（1）定義

緩存中沒有數據，數據庫也沒有相應的數據，但有用戶一直在發起這個都沒有的請求，而且請求的數據格式很大。這種情況一般是黑客利用漏洞攻擊，壓垮應用數據庫

（2）解決方式：專門的安全人員處理

二、redis的集群架構

1、高可用方案

（1）主從復制

（2）哨兵模式

（3）redis集群

2、主從復制

（1）主從復制是redis實現高可用的基礎，哨兵模式和集群都是在主從復制的基礎上實現高可用

（2）主從復制實現數據的多機備份和讀寫分離（主服務器——寫，從服務器——讀）

缺點：故障無法自動恢復，需人工干預，無法實現寫操作的負載均衡

3、主從復制的工作原理

由主節點master和從節點slave組成，數據復制是單向的，只能從主節點到從節點

4、哨兵模式

在主從復制的基礎上實現主節點故障的自動切換

（1）哨兵模式定義

哨兵是一個分布式系統，用于在主從結構之間，對每臺redis服務進行監控。主節點出現故障時，從節點通過投票的方式選擇一個新的master

哨兵模式也需要至少三個節點

（2）哨兵模式的結構

①哨兵節點：監控主、從節點，不存儲數據

②數據節點：主節點和從節點，都是數據節點

（哨兵1監控從1，從2節點；哨兵2監控主節點，從2 節點；哨兵3監控主節點，從1節點）

（2）哨兵模式工作原理

每個哨兵節點每隔一秒，通過ping命令方式，檢測主、從之間的心跳線，主節點在一定時間內沒有回復或回復了錯誤消息，這個時候哨兵會主觀認為主節點下線了；超過半數的哨兵節點認為主節點下線了，這個時候才會認為主節點是客觀下線

故障恢復可能會有延遲，因為有一個選舉過程

（4）如何選舉新的主節點

哨兵節點通過raft算法（選舉算法），每個節點共同投票選舉出一個新的master，然后新的master實現主節點的轉移和故障恢復通知

（5）主節點的選舉過程

①已下線的從節點不會被選為主節點

②選擇配置文件中從節點優先級最高的replica-priority 100

③自動選擇一個復制數據最完整的從節點

三、主從復制+哨兵模式實驗

基于主從復制做哨兵模式實驗

實驗目的：解決redis單節點故障問題

實驗條件：

IP地址	作用	組件
20.0.0.14	主服務器	redis服務
20.0.0.24	從服務器1	redis服務
20.0.0.34	從服務器2	redis服務

實驗步驟：

1、主從復制實驗

（1）配置主服務器

（2）配置從服務器

從1

從2

replicaof 20.0.0.14 6379表示只讀（20.0.0.14是主服務器的IP地址）

主從復制完成

（3）測試

2、哨兵模式實驗

（1）配置主服務器

這個2：一般設置成集群的一半

最小切換時間30秒

最大切換時間180秒

（2）配置從服務器

從1

從2（與從1同樣的配置）

（3）啟動主從服務器（先啟動主再啟動從）

redis-sentinel sentinel.conf &

監控哨兵集群的信息redis-cli -p 26379 info Sentinel

哨兵模式搭建完畢

查看從節點信息tail -f /var/log/sentinel.log

（4）故障切換

模擬故障

看日志是否主從切換，有延遲

tail -f /var/log/sentinel.log

目前，新主的IP地址是20.0.0.34

（5）測試

①測試新主能不能寫

能

恢復原主

②測試原主能否繼續寫

不能

原因：配置文件/etc/redis/6379.conf發生變化

原主（現從2）

從1

原從2（新主）