一、概述

1.1 背景介紹

Redis 主從復制解決了讀擴展和數據冗余問題，但主節點故障時需要人工介入切換，這在生產環境中是不可接受的。Sentinel（哨兵）模式在主從架構之上增加了自動故障檢測和故障轉移能力，是 Redis 高可用的標準方案之一。

Sentinel 本質上是一組獨立進程，持續監控 Redis 主從節點的健康狀態，在主節點不可用時自動完成新主節點選舉和客戶端重定向。Redis 8.x 對 Sentinel 的穩定性和性能做了進一步優化，但核心機制與 7.x 保持一致。

1.2 技術特點

自動故障轉移：主節點宕機后無需人工干預，Sentinel 集群自動完成切換，通常在 30 秒內完成

服務發現：客戶端通過 Sentinel 獲取當前主節點地址，屏蔽了主從切換的地址變化

配置傳播：故障轉移完成后，Sentinel 自動更新所有從節點的復制配置

多 Sentinel 協作：通過 quorum 機制避免單點誤判，防止網絡抖動觸發不必要的切換

1.3 適用場景

數據量在單機可承載范圍內（通常 < 100GB），不需要數據分片

對寫入可用性要求高，能接受切換期間約 30 秒的寫入中斷

讀寫比高，通過從節點分擔讀流量

不需要 Cluster 的水平擴展能力，但需要比單主更高的可用性

1.4 環境要求

組件	版本要求	說明
Redis	8.x	主從節點和 Sentinel 版本保持一致
操作系統	Linux（內核 4.x+）	需要穩定的網絡棧
節點數量	最少 3 個 Sentinel	保證 quorum 投票的奇數原則
網絡延遲	< 10ms（Sentinel 節點間）	延遲過高影響故障檢測準確性

二、詳細步驟

2.1 Sentinel 工作原理

2.1.1 主觀下線與客觀下線

理解這兩個概念是正確配置 Sentinel 的基礎。

主觀下線（SDOWN，Subjectively Down）：單個 Sentinel 實例認為某節點不可用。判斷依據是在down-after-milliseconds時間內沒有收到節點的有效響應（PING 返回 PONG 或錯誤響應）。SDOWN 只是單個 Sentinel 的主觀判斷，不會觸發故障轉移。

客觀下線（ODOWN，Objectively Down）：多個 Sentinel 實例都認為主節點不可用，且達到 quorum 數量。只有主節點才有 ODOWN 狀態，從節點和 Sentinel 節點只有 SDOWN。ODOWN 是觸發故障轉移的前提條件。

Sentinel A: PING master → 無響應 → 標記 master SDOWN
Sentinel A: 詢問 Sentinel B、C →"你們也認為 master 掛了嗎？"
Sentinel B:"是的，我也收不到響應"
Sentinel C:"我也是"
達到 quorum=2 → Sentinel A 標記 master ODOWN → 開始 Leader 選舉

2.1.2 故障轉移流程

Leader 選舉：Sentinel 集群通過 Raft 協議選出一個 Leader，由 Leader 負責執行故障轉移

新主節點選擇：Leader 從可用從節點中按以下優先級選擇新主節點：

replica-priority（slave-priority）值最小的優先（0 表示永不成為主節點）

復制偏移量最大的優先（數據最新）

Run ID 字典序最小的優先（決勝條件）

執行切換：向選中的從節點發送REPLICAOF NO ONE，使其成為新主節點

重新配置：通知其他從節點復制新主節點，更新 Sentinel 配置文件

通知客戶端：通過 Pub/Sub 頻道+switch-master發布切換事件

2.2 3節點 Sentinel 集群配置

2.2.1 節點規劃

節點角色    IP       端口
Redis 主節點  10.0.1.10    6379
Redis 從節點1  10.0.1.11    6379
Redis 從節點2  10.0.1.12    6379
Sentinel 1   10.0.1.10    26379
Sentinel 2   10.0.1.11    26379
Sentinel 3   10.0.1.12    26379

Sentinel 和 Redis 節點共用機器是常見的部署方式，節省資源。但要確保 Sentinel 進程和 Redis 進程的故障是獨立的——Redis 掛了不代表 Sentinel 也掛。

2.2.2 Redis 主節點配置

# 文件路徑：/etc/redis/redis.conf（主節點 10.0.1.10）
bind 10.0.1.10 127.0.0.1
port 6379
daemonize yes
pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

# 持久化配置
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

# 認證密碼（主從和 Sentinel 必須一致）
requirepass "Redis@Secure2024!"
masterauth "Redis@Secure2024!"

# 內存配置
maxmemory 8gb
maxmemory-policy allkeys-lru

# 腦裂防護：至少 1 個從節點同步才接受寫入
min-replicas-to-write 1
min-replicas-max-lag 10

2.2.3 Redis 從節點配置

# 文件路徑：/etc/redis/redis.conf（從節點 10.0.1.11 和 10.0.1.12）
bind 10.0.1.11 127.0.0.1  # 10.0.1.12 節點改為對應 IP
port 6379
daemonize yes
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

# 指定主節點
replicaof 10.0.1.10 6379

# 認證
requirepass "Redis@Secure2024!"
masterauth "Redis@Secure2024!"

# 從節點只讀（默認已是 yes，顯式聲明更清晰）
replica-read-only yes

# 從節點優先級（數值越小越優先成為新主節點）
# 10.0.1.11 設為 100，10.0.1.12 設為 200，優先選 .11 作為新主
replica-priority 100

# 持久化
appendonly yes
appendfsync everysec

2.2.4 Sentinel 配置

三個 Sentinel 節點使用相同的配置文件，只有bind地址不同：

# 文件路徑：/etc/redis/sentinel.conf
# 三個節點分別修改 bind 為各自 IP

bind 10.0.1.10 127.0.0.1  # 節點1；節點2改為10.0.1.11；節點3改為10.0.1.12
port 26379
daemonize yes
pidfile /var/run/redis/redis-sentinel.pid
logfile /var/log/redis/sentinel.log
dir /var/lib/redis

# 監控主節點，quorum=2 表示需要 2 個 Sentinel 同意才能觸發故障轉移
sentinel monitor mymaster 10.0.1.10 6379 2

# 主節點認證密碼
sentinel auth-pass mymaster Redis@Secure2024!

# 主節點超過 5000ms 無響應，標記為 SDOWN
sentinel down-after-milliseconds mymaster 5000

# 故障轉移超時時間：3 分鐘內未完成則認為失敗
sentinel failover-timeout mymaster 180000

# 故障轉移后，同時向新主節點同步的從節點數量
# 設為 1 表示逐個同步，避免所有從節點同時不可讀
sentinel parallel-syncs mymaster 1

# Sentinel 自身的訪問密碼（Redis 6.2+ 支持）
requirepass "Sentinel@Secure2024!"
sentinel sentinel-pass Sentinel@Secure2024!

2.2.5 啟動順序

# 1. 先啟動主節點
systemctl start redis-server # 10.0.1.10

# 2. 啟動從節點
systemctl start redis-server # 10.0.1.11 和 10.0.1.12

# 3. 驗證主從復制狀態
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'info replication

# 預期輸出關鍵字段：
# role:master
# connected_slaves:2
# slave0:ip=10.0.1.11,port=6379,state=online,offset=xxx,lag=0
# slave1:ip=10.0.1.12,port=6379,state=online,offset=xxx,lag=0

# 4. 啟動 Sentinel（三個節點都要啟動）
redis-sentinel /etc/redis/sentinel.conf
# 或
systemctl start redis-sentinel

# 5. 驗證 Sentinel 狀態
redis-cli -h 10.0.1.10 -p 26379 -a'Sentinel@Secure2024!'sentinel masters

2.3 驗證故障轉移

# 模擬主節點故障
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'DEBUG sleep 30

# 在另一個終端觀察 Sentinel 日志
tail -f /var/log/redis/sentinel.log

# 預期日志序列：
# +sdown master mymaster 10.0.1.10 6379
# +odown master mymaster 10.0.1.10 6379#quorum2/2
# +try-failover master mymaster 10.0.1.10 6379
# +elected-leader master mymaster 10.0.1.10 6379
# +selected-slave slave 10.0.1.11:6379 mymaster 10.0.1.10 6379
# +promoted-slave slave 10.0.1.11:6379 mymaster 10.0.1.10 6379
# +switch-master mymaster 10.0.1.10 6379 10.0.1.11 6379

# 故障轉移完成后，查詢新主節點
redis-cli -h 10.0.1.10 -p 26379 -a'Sentinel@Secure2024!'sentinel get-master-addr-by-name mymaster

三、示例代碼和配置

3.1 客戶端接入 Sentinel

客戶端不能直連 Redis 主節點 IP，必須通過 Sentinel 獲取當前主節點地址，否則主從切換后客戶端無法自動重連。

3.1.1 Python（redis-py）

importredis
fromredis.sentinelimportSentinel

# 連接 Sentinel 集群
sentinel = Sentinel(
  [
    ('10.0.1.10',26379),
    ('10.0.1.11',26379),
    ('10.0.1.12',26379),
  ],
  socket_timeout=0.5,
  sentinel_kwargs={'password':'Sentinel@Secure2024!'}
)

# 獲取主節點連接（自動處理故障轉移后的地址變更）
master = sentinel.master_for(
 'mymaster',
  socket_timeout=0.5,
  password='Redis@Secure2024!',
  db=0,
  retry_on_timeout=True
)

# 獲取從節點連接（讀操作）
slave = sentinel.slave_for(
 'mymaster',
  socket_timeout=0.5,
  password='Redis@Secure2024!',
  db=0
)

# 寫操作走主節點
master.set('key','value', ex=3600)

# 讀操作走從節點
value = slave.get('key')

3.1.2 Java（Jedis）

importredis.clients.jedis.JedisSentinelPool;
importredis.clients.jedis.Jedis;
importredis.clients.jedis.JedisPoolConfig;
importjava.util.HashSet;
importjava.util.Set;

// 配置連接池
JedisPoolConfig poolConfig =newJedisPoolConfig();
poolConfig.setMaxTotal(50);
poolConfig.setMaxIdle(10);
poolConfig.setMinIdle(5);
poolConfig.setTestOnBorrow(true);

// Sentinel 節點集合
Set sentinels =newHashSet<>();
sentinels.add("10.0.1.10:26379");
sentinels.add("10.0.1.11:26379");
sentinels.add("10.0.1.12:26379");

// 創建 Sentinel 連接池
JedisSentinelPool sentinelPool =newJedisSentinelPool(
 "mymaster",
  sentinels,
  poolConfig,
 2000,     // connectionTimeout
 2000,     // soTimeout
 "Redis@Secure2024!", // Redis 密碼
 0,       // database
 null,     // clientName
 0,       // sentinelConnectionTimeout
 0,       // sentinelSoTimeout
 "Sentinel@Secure2024!", // Sentinel 密碼
 null     // sentinelClientName
);

// 使用連接
try(Jedis jedis = sentinelPool.getResource()) {
  jedis.set("key","value");
  String value = jedis.get("key");
}

3.2 Sentinel 監控腳本

#!/bin/bash
# 文件名：/opt/redis/scripts/sentinel_check.sh
# 功能：檢查 Sentinel 集群健康狀態，輸出關鍵指標

SENTINEL_HOSTS=("10.0.1.10""10.0.1.11""10.0.1.12")
SENTINEL_PORT=26379
SENTINEL_PASS="Sentinel@Secure2024!"
MASTER_NAME="mymaster"

echo"===== Sentinel 集群狀態檢查 ====="
echo"時間:$(date)"
echo""

# 檢查每個 Sentinel 節點
forhostin"${SENTINEL_HOSTS[@]}";do
 echo"--- Sentinel:${host}:${SENTINEL_PORT}---"

 # 獲取當前主節點地址
  master_info=$(redis-cli -h"${host}"-p"${SENTINEL_PORT}"
    -a"${SENTINEL_PASS}"--no-auth-warning 
    sentinel get-master-addr-by-name"${MASTER_NAME}"2>/dev/null)

 if[ $? -eq 0 ];then
    master_ip=$(echo"${master_info}"| head -1)
    master_port=$(echo"${master_info}"| tail -1)
   echo" 當前主節點:${master_ip}:${master_port}"
 else
   echo" [ERROR] 無法連接 Sentinel"
   continue
 fi

 # 獲取 Sentinel 詳細信息
  sentinel_info=$(redis-cli -h"${host}"-p"${SENTINEL_PORT}"
    -a"${SENTINEL_PASS}"--no-auth-warning 
    sentinel masters 2>/dev/null)

 # 提取關鍵字段
  num_slaves=$(echo"${sentinel_info}"| grep -A1"num-slaves"| tail -1)
  num_sentinels=$(echo"${sentinel_info}"| grep -A1"num-other-sentinels"| tail -1)
  quorum=$(echo"${sentinel_info}"| grep -A1"quorum"| tail -1)
  flags=$(echo"${sentinel_info}"| grep -A1"^flags$"| tail -1)

 echo" 從節點數量:${num_slaves}"
 echo" 其他 Sentinel 數量:${num_sentinels}"
 echo" Quorum:${quorum}"
 echo" 主節點狀態:${flags}"
 echo""
done

3.3 腦裂防護配置詳解

腦裂（Split-Brain）是 Sentinel 模式最危險的場景：主節點因網絡分區與 Sentinel 失聯，Sentinel 誤判主節點宕機并選出新主節點，此時集群中存在兩個主節點，客戶端寫入數據后，網絡恢復時舊主節點的數據會被覆蓋丟失。

# 在主節點 redis.conf 中配置
# 含義：至少有 1 個從節點在線且復制延遲不超過 10 秒，才接受寫入
# 當主節點與所有從節點斷開（網絡分區場景），主節點自動拒絕寫入
min-replicas-to-write 1
min-replicas-max-lag 10

這個配置的代價是：當從節點全部宕機或網絡延遲超過 10 秒時，主節點會拒絕寫入，業務會報錯。這是一個可用性和一致性之間的權衡，對數據一致性要求高的場景（金融、訂單）應該開啟，對可用性優先的場景（緩存、會話）可以不開啟。

四、最佳實踐和注意事項

4.1 最佳實踐

4.1.1 Sentinel 節點部署

奇數原則：Sentinel 節點數量必須是奇數（3、5、7），quorum 設為(n/2)+1。3 節點集群 quorum=2，允許 1 個 Sentinel 故障；5 節點集群 quorum=3，允許 2 個故障。不要部署 2 個 Sentinel，quorum=2 時任意一個故障都會導致無法完成故障轉移。

跨機架部署：3 個 Sentinel 節點分布在 3 個不同的物理機架或可用區，避免單機架故障導致 Sentinel 集群失去 quorum。

Sentinel 與 Redis 分離：資源充足時，Sentinel 進程部署在獨立機器上，避免 Redis 進程消耗大量內存時影響 Sentinel 的心跳響應。

4.1.2 故障轉移參數調優

down-after-milliseconds直接決定故障檢測速度和誤判率之間的平衡：

設置過?。? 3000ms）：網絡抖動、GC 停頓、系統負載高峰都可能觸發誤判

設置過大（> 30000ms）：真實故障的檢測時間過長，業務中斷時間延長

推薦值：5000-10000ms，結合業務對中斷時間的容忍度決定

4.1.3 持久化配置

Sentinel 模式下主從節點都應開啟 AOF 持久化，appendfsync設為everysec。如果主節點關閉持久化，主節點重啟后會以空數據集啟動，從節點同步后數據全部丟失——這是一個經典的數據丟失場景。

4.2 注意事項

4.2.1 配置注意事項

警告：Sentinel 在完成故障轉移后會自動修改sentinel.conf文件。如果用配置管理工具（Ansible、Chef）管理該文件，必須排除 Sentinel 自動寫入的字段，否則下次配置推送會覆蓋 Sentinel 的狀態記錄，導致集群狀態混亂。

不要在 Sentinel 運行時手動編輯sentinel.conf

主從節點的requirepass和masterauth必須設置為相同的密碼

故障轉移完成后，原主節點恢復時會自動降級為從節點，不需要手動干預

4.2.2 常見錯誤

錯誤現象	原因分析	解決方案
Sentinel 持續出現+sdown但不觸發故障轉移	quorum 未達到，部分 Sentinel 節點無法通信	檢查 Sentinel 節點間的網絡連通性和防火墻規則
故障轉移后客戶端仍連接舊主節點	客戶端硬編碼了主節點 IP	改造客戶端使用 Sentinel 連接池
從節點復制延遲持續增大	主節點寫入量超過從節點同步能力	增大repl_backlog_size，檢查網絡帶寬
Sentinel 選舉超時，故障轉移失敗	failover-timeout 設置過小	增大failover-timeout，檢查 Sentinel 節點網絡

4.3 Sentinel vs Cluster 選型

選 Sentinel 的場景：數據量在單機內存范圍內、寫入 QPS < 10 萬、需要強一致的 Lua 腳本或事務操作。

選 Cluster 的場景：數據量超過單機內存、寫入 QPS 超過單主節點瓶頸、需要線性擴展寫入能力。

五、故障排查和監控

5.1 故障排查

5.1.1 日志查看

# 實時查看 Sentinel 日志
tail -f /var/log/redis/sentinel.log

# 查看最近的故障轉移記錄
grep"switch-master|failover|odown"/var/log/redis/sentinel.log | tail -50

# 查看主節點復制狀態
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'info replication

# 查看復制延遲（lag 字段，單位秒）
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'
 info replication | grep"slave[0-9]"

5.1.2 常見問題排查

問題一：Sentinel 無法發現從節點

# 檢查 Sentinel 已知的從節點列表
redis-cli -h 10.0.1.10 -p 26379 -a'Sentinel@Secure2024!'
 sentinel slaves mymaster

# Sentinel 通過主節點的 INFO 命令發現從節點
# 如果從節點未出現，檢查從節點的 replicaof 配置是否正確
redis-cli -h 10.0.1.11 -p 6379 -a'Redis@Secure2024!'info replication

問題二：故障轉移后舊主節點無法加入集群

# 舊主節點恢復后，檢查其角色
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'info replication

# 如果仍顯示 role:master，手動設置為從節點
redis-cli -h 10.0.1.10 -p 6379 -a'Redis@Secure2024!'
 replicaof 10.0.1.11 6379

5.2 性能監控

5.2.1 監控指標說明

指標名稱	正常范圍	告警閾值	說明
復制延遲（lag）	0-1 秒	> 10 秒	從節點數據落后主節點的時間
connected_slaves	等于從節點數	< 預期數量	在線從節點數量
Sentinel 響應時間	< 5ms	> 100ms	Sentinel 進程健康狀態
master_last_io_seconds_ago	< 5	> 30	主從最后通信時間間隔
repl_backlog_active	1	0	復制積壓緩沖區是否活躍

5.3 備份與恢復

#!/bin/bash
# 從從節點備份，避免影響主節點性能
SLAVE_HOST="10.0.1.11"
REDIS_PASS="Redis@Secure2024!"
BACKUP_DIR="/opt/redis/backups"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p"${BACKUP_DIR}"

# 觸發從節點 BGSAVE
redis-cli -h"${SLAVE_HOST}"-p 6379 -a"${REDIS_PASS}"--no-auth-warning BGSAVE

# 等待完成
sleep 5

# 復制 RDB 文件
cp /var/lib/redis/dump.rdb"${BACKUP_DIR}/dump_${DATE}.rdb"
echo"備份完成:${BACKUP_DIR}/dump_${DATE}.rdb"

# 保留最近 7 天
find"${BACKUP_DIR}"-name"dump_*.rdb"-mtime +7 -delete

六、總結

6.1 技術要點回顧

SDOWN vs ODOWN：單個 Sentinel 的主觀判斷不觸發切換，需要達到 quorum 數量的 Sentinel 共同確認才進入客觀下線狀態

quorum 配置：3 節點集群設為 2，是可用性和防誤判的最佳平衡點

腦裂防護：min-replicas-to-write讓主節點在網絡分區時主動拒絕寫入，避免數據丟失

客戶端接入：必須通過 Sentinel 發現主節點地址，不能硬編碼 Redis 主節點 IP

replica-priority：通過優先級控制故障轉移時的新主節點選擇

6.2 進階學習方向

Redis Cluster：當單主節點無法承載數據量或寫入壓力時，Cluster 是下一步演進方向

Sentinel 與 Proxy 結合：在 Sentinel 前部署 Twemproxy 或 Codis，對客戶端屏蔽 Sentinel 發現邏輯

Redis 持久化深度優化：AOF rewrite 策略、RDB 與 AOF 混合持久化對故障恢復時間的影響

6.3 參考資料

Redis Sentinel 官方文檔

Redis 8.x Release Notes

Redis 高可用架構設計

附錄

A. 命令速查表

# 查詢當前主節點地址
redis-cli -p 26379 -a'pass'sentinel get-master-addr-by-name mymaster

# 查看所有主節點信息
redis-cli -p 26379 -a'pass'sentinel masters

# 查看從節點列表
redis-cli -p 26379 -a'pass'sentinel slaves mymaster

# 查看其他 Sentinel 節點
redis-cli -p 26379 -a'pass'sentinel sentinels mymaster

# 手動觸發故障轉移（測試用）
redis-cli -p 26379 -a'pass'sentinel failover mymaster

# 重置 Sentinel 狀態
redis-cli -p 26379 -a'pass'sentinel reset mymaster

B. 配置參數詳解

參數	默認值	說明
down-after-milliseconds	30000	節點無響應多少毫秒后標記為 SDOWN
failover-timeout	180000	故障轉移超時時間（毫秒）
parallel-syncs	1	故障轉移后同時同步的從節點數量
quorum	需手動設置	觸發 ODOWN 所需的最少 Sentinel 數量
min-replicas-to-write	0	主節點接受寫入所需的最少在線從節點數
min-replicas-max-lag	10	從節點復制延遲超過此值（秒）視為不可用

C. 術語表

術語	英文	解釋
主觀下線	SDOWN (Subjectively Down)	單個 Sentinel 認為節點不可用
客觀下線	ODOWN (Objectively Down)	多個 Sentinel 共同確認節點不可用
仲裁數	Quorum	觸發故障轉移所需的最少 Sentinel 同意數
腦裂	Split-Brain	網絡分區導致集群中出現兩個主節點的場景
復制積壓	Replication Backlog	主節點保存的最近寫命令緩沖區，用于斷線重連后的增量同步