Redis筆記（三）常見的持久化開發運維問題 & Redis複製的原理與優化 & Redis Sentinel

常見的持久化開發運維問題 & Redis複製的原理與優化 & Redis Sentinel

第6章 常見的持久化開發運維問題

本章探討了常見的持久化問題進行定位和優化，最後結合Redis常見的單機多實例部署場景進行優化

6-1 常見問題目錄

1. fork操作
2. 進程外開銷
3. AOF追加阻塞
4. 單機多實例部署

6-2 fork

1. 同步操作
2. 與內存量息息相關：內存越大，耗時越長（與機器類型有關）
3. info:latest_fork usec #查詢 上一次持久化所消耗的時間

改善fork

1. 優先使用物理機或者高效支持fork操作的虛擬化技術
2. 控制Redis實例最大可用內存：maxmemory
3. 合理配置Linux內存分配策略：Vm.overcommit_memory=1 #但還有足夠內存是允許進行分配
4. 降低fork頻率：例如放寬AOF重寫自動觸發時機，不必要的全量複製

6-3 子進程開銷和優化

1. CPU：
   開銷：RDB和AOF文件生成，屬於CPU密集型
   優化：不做CPU綁定，不和CPU密集型部署
2. 內存
   開銷：fork內存開銷，copy-on-write。
   優化：echo never>/sys/kernel/mm/transparent_ hugepage/enabled
3. 硬盤
   開銷：AOF和RDB文件寫入，可以結合iostat，iotop分析

硬盤優化

1. 不要和高硬盤負載服務部署一起：存儲服務、消息隊列等
2. no-appendfsync-on-rewrite=yes #在aof重寫期間不要進行追加的操作 可以減少內存開銷
3. 根據寫入量決定磁盤類型：例如ssd
4. 單機多實例持久化文件目錄可以考慮分盤

6-4 AOF阻塞

AOF阻塞定位

1. 通過日誌

Redis日誌：
Asynchronous AOF fsync is taking too long（disk is busy？）.
Writing the AOF buffer without waiting for fsync to complete，
this may slow down Redis

2. 通過info Persistence

127.0.0.1:6379>info persistence

3. 直接查看是否緊張

第7章 Redis複製的原理與優化

複製是實現高可用的基石，但複製同樣是運維的痛點，本部分詳細分析複製的原理，講解運維過程中可能遇到的問題。

7-1 目錄

7-2 什麼是主從複製

單機有什麼問題？

• 機器故障
• 容量瓶頸
• QPS瓶頸

一主一從

一主多從

主從複製作用

• 數據副本
• 擴展讀性能

7-3 複製的配置

兩種實現方式

方式一：slaveof命令

使用命令進行實現

取消複製

redis-6380>slaveof no one
OK

執行該命令後 6379新寫入的數據將不會再同步到 6380

redis-6380> slaveof 127.0.0.1 6379
OK

方式二：修改配置

slaveof ip port #成爲某一臺機器的從節點
slave-read-only yes#從節點只做讀的操作 保證主從節點的一致性 

兩種方式比較

實驗

對應 Redis筆記（三）實驗部分 : 主從複製的配置與實現

7-4 全量複製和部分複製

全量複製

將主節點在複製過程中寫入的數據也同步給從節點

在第一次請求中 由於不知道主節點的 runid和偏移量 所以要發送 psync? -1 然後主節點 發送給從節點runid和偏移量 然後從節點進行保存主節點的基本信息
然後主節點執行bgsava 而在rdb生成到rdb傳輸的這段時間內的新增命令需要進行一個保存（在buffuf區中）然後在發送 rdb之後 會send buffer最後在進行數據寫入

全量複製開銷

1. bgsave時間
2. RDB文件網絡傳輸時間
3. 從節點清空數據時間
4. 從節點加載RDB的時間
5. 可能的AOF重寫時間

部分複製

如果在全量複製的過程中發生網絡抖動 就需要再次進行全量複製效率較低 而部分複製如果在連接的過程中主從節點斷開 主節點就會向緩衝區中寫入命令
當從節點再次連接上主節點之後 從節點會發送pysnc{offset}{runld} 此時主節點如果發現從節點的偏移量是在他的buffer範圍內則會返回從偏移量開始到結束的數據

7-5 故障處理

故障處理：故障轉移
故障分爲兩種

slave 宕掉

master 宕掉

解決方案：將主節點進行遷移

7-6 主從複製常見問題

◆讀寫分離

1. 讀寫分離：讀流量分攤到從節點。
2. 可能遇到問題：
   ·複製數據延遲
   ·讀到過期數據
   ·從節點故障
   

◆主從配置不一致

1. 例如maxmemory不一致：丟失數據
2. 例如數據結構優化參數（例如hash-max-ziplist-entries）：內存不一致

◆ 規避全量複製

1. 第一次全量複製
   第一次不可避免·小主節點、低峯
2. 節點運行ID不匹配
   主節點重啓（運行ID變化）
   故障轉移，例如哨兵或集羣
3. 複製積壓緩衝區不足
   網絡中斷，部分複製無法滿足
   增大複製緩衝區配置rel_backlog_size，網絡“增強"。

◆ 規避複製風暴

1. 單主節點複製風暴：
   問題：主節點重啓，多從節點複製，主節點壓力較大
   解決：更換複製拓撲
   
2. 單機器複製風暴
   如右圖：機器宕機後（假設該機器上均爲主節點），則會大量全量複製
   解決辦法：主節點分散多機器上
   

第8章 Redis Sentinel

本章將一步步解析Redis Sentinel的相關概念、安裝部署、配置、客戶端路由、原理解析，最後分析了Redis Sentinel運維中的一些問題。

8-1 sentinel-目錄

◆主從複製高可用？
◆架構說明
◆安裝配置
◆客戶端連接
◆實現原理
◆常見開發運維問題

8-2 主從複製高可用？

之前主從複製中存在的問題：

1. 手動故障轉移
2. 寫能力（只能寫在一個節點上）和存儲能力受限
   
   之前一旦主節點掛掉 就需要手動或者使用腳本來進行故障轉移，而轉移的過程中涉及到許多問題。普通開發人員難以實現，而redis sentinel 則提供了這樣一些功能來幫我們解決這些問題。

8-3 redis sentinel架構

實現了類似於 監控節點是否有問題，完美的遷移流程，以及如何通知客戶端

故障轉移

可以使用 同一redis sentinel 來監控多個redis master

8-4 redis sentinel安裝與配置

1. 配置開啓主從節點
2. 配置開啓sentinel監控主節點。（sentinel是特殊的redis）
3. 實際應該多機器
4. 詳細配置節點

8-5 redis sentinel安裝演示-1

8-6 redis sentinel安裝演示-2

8-7 java客戶端

8-8 python客戶端

8-9 實現原理-1-故障轉移演練

8-10 實現原理-2.故障轉移演練(客戶端)

8-11 實現原理-3.故障演練(日誌分析)

以上幾個部分對應 ：
Redis筆記（三）實驗部分：Redis Sentinel的配置與安裝&Java客戶端連接 Redis Sentinel&故障轉移演練

8-12 三個定時任務

1. 每10秒每個sentinel對master和slave執行info
   ·發現slave節點
   ·確認主從關係
   
2. 每2秒每個sentinel通過master節點的channel交換信息（pub/sub）
   ·通過_sentinel__：hello頻道交互
   ·交互對節點的“看法”和自身信息
   
3. 每1秒每個sentinel對其他sentinel和redis執行ping
   ·心跳檢測，失敗判定依據

8-13 主觀下線和客觀下線

sentinel monitor  <masterName> <ip> <port> <quorum>
sentinel monitor myMaster 127.0.0.1 6379 2
sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

·主觀下線：每個sentinel節點對Redis節點失敗的“偏見"

·客觀下線：所有sentinel節點對Redis節點失敗“達成共識"（超過
quorum個統一）
sentinel is-master-down-by-addr

8-14 領導者選舉

·原因：只有一個sentinel節點完成故障轉移

·選舉：通過sentinel is-master-down-by-addr命令都希望成爲領導者

1. 每個做主觀下線的Sentinel節點向其他Sentinel節點發送命令，要求將它設置爲領導者。
2. 收到命令的Sentinel節點如果沒有同意通過其他Sentinel節點發送的命令，那麼將同意該請求，否則拒絕
3. 如果該Sentinel節點發現自己的票數已經超過Sentinel集合半數且超過quorum，那麼它將成爲領導者。
4. 如果此過程有多個Sentinel節點成爲了領導者，那麼將等待一段時間重新進行選舉。
   

8-15 故障轉移（sentinel領導者節點完成）

1. 從slave節點中選出一個“合適的"節點作爲新的master節點
2. 對上面的slave節點執行slaveof no one命令讓其成爲master節點。
3. 向剩餘的slave節點發送命令，讓它們成爲新master節點的slave節點，複製規則和parallel-syncs參數有關。
4. 更新對原來master節點配置爲slave，並保持着對其“關注"，當其恢復後命令它去複製新的master節點。

選擇“合適的"slave節點

1. 選擇slave-priority（slave節點優先級）最高的slave節點，如果存在則返回，不存在則繼續。
2. 選擇複製偏移量最大的slave節點（複製的最完整），如果存在則返回，不存在則繼續。
3. 選擇runld最小的slave節點。

8-16 常見開發運維問題-目錄

◆節點運維◆高可用讀寫分離

8-17 節點運維

節點下線
機器下線：例如過保等情況
機器性能不足導致下線：例如CPU、內存、硬盤、網絡等
節點自身故障導致下線：例如服務不穩定等

◆主節點
使用命令手動下線：

◆從節點：臨時下線還是永久下線，例如是否做一些清理工作。
但是要考慮讀寫分離的情況。

◆Sentinel節點：同上。

節點上線
◆主節點：sentinel failover進行替換。

◆從節點：slaveof即可，sentinel節點可以感知。

◆sentinel節點：參考其他sentinel節點啓動即可。

8-18 高可用讀寫分離

◆+switch-master：切換主節點（從節點晉升主節點）
◆+convert-to-slave：切換從節點（原主節點降爲從節點）
◆+sdown：主觀下線。