Redis 部署模式詳解

Redis 支持多種部署模式，主要包括單機模式（Single）、哨兵模式（Sentinel）、集群模式（Cluster）及增強代理集群，分別適用于不同場景，以下是它們的詳細介紹。以下說明僅適用于 Redis 7.0+。

一、單機模式（Single）

1. 簡介

（1）最簡單的部署方式，僅運行單個 Redis 實例。

（2）無高可用性，如果實例崩潰，服務不可用。

（3）適用場景：開發(fā)環(huán)境。

2. 配置方法

（1）修改 redis.conf

# 綁定 IP（默認僅本地訪問）
bind 0.0.0.0  # 允許遠程訪問
# 設置密碼（可選）
requirepass yourpassword
# 持久化配置（默認啟用 RDB）
save 900 1      # 15 分鐘內至少 1 次修改則保存
save 300 10     # 5 分鐘內至少 10 次修改則保存
save 60 10000   # 1 分鐘內至少 10000 次修改則保存
# 啟用 AOF（可選）
appendonly yes
appendfilename "appendonly.aof"

（2）啟動 Redis

redis-server /path/to/redis.conf

（3）客戶端連接

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword

二、哨兵模式（Sentinel）

1. 簡介

（1）整體設計：主從架構 + 自動故障轉移，提供高可用性（HA）。

（2）部署方式：1 個主節(jié)點（Master） + N 個從節(jié)點（Replica）+ M 個 Sentinel 節(jié)點。

（3）適用場景：需要高可用但不需要數據分片（水平擴展）的場景。

2. 整體架構

組成部分：

（1）1 個主節(jié)點（Master）：負責寫入和數據存儲。

（2）N 個從節(jié)點（Replica）：復制主節(jié)點數據，提供讀能力。

（3）M 個哨兵節(jié)點（Sentinel）：監(jiān)控主從狀態(tài)，觸發(fā)故障轉移。

執(zhí)行流程：

（1）監(jiān)控（Monitoring）

• 每個 Sentinel 定期檢查 Master 和 Replica 是否存活（默認每秒 1 次）。
• 若 Master 未響應超過 down-after-milliseconds（如 30 秒），Sentinel 標記其為 主觀下線（SDOWN）。

（2）選舉（Leader Election）

• 當多數 Sentinel（>= quorum 配置值）確認 Master 下線，標記為 客觀下線（ODOWN）。
• Sentinel 集群通過 Raft 協(xié)議選舉一個 Leader Sentinel 來執(zhí)行故障轉移。

（3）故障轉移（Failover）

• Leader Sentinel 選擇一個最優(yōu)的 Replica 提升為新的 Master。
• 通知其他 Replica 復制新 Master。
• 更新客戶端連接信息（通過 +switch-master 事件通知）。

（4）客戶端重定向

• 客戶端通過 Sentinel 獲取最新的 Master 地址（如 SENTINEL get-master-addr-by-name mymaster）。

交互流程：

3. 配置方法

（1）主節(jié)點配置（redis-master.conf）

bind 0.0.0.0
requirepass yourpassword
masterauth yourpassword  # 從節(jié)點訪問主節(jié)點的密碼

（2）從節(jié)點配置（redis-replica.conf）

bind 0.0.0.0
requirepass yourpassword
replicaof 127.0.0.1 6379  # 指向主節(jié)點
masterauth yourpassword   # 主節(jié)點密碼

（3）哨兵配置（sentinel.conf）

sentinel monitor mymaster 127.0.0.1 6379 2  # 監(jiān)控主節(jié)點，2 表示至少 2 個 Sentinel 同意才觸發(fā)故障轉移
sentinel auth-pass mymaster yourpassword    # 主節(jié)點密碼
sentinel down-after-milliseconds mymaster 5000  # 5 秒無響應視為下線
sentinel failover-timeout mymaster 60000   # 故障轉移超時時間（60 秒）

（4）啟動服務

# 啟動主節(jié)點
redis-server redis-master.conf
# 啟動從節(jié)點
redis-server redis-replica.conf
# 啟動 Sentinel
redis-sentinel sentinel.conf

（5）驗證故障轉移

# 查看主從信息
redis-cli -p 6379 INFO replication
# 手動關閉主節(jié)點，觀察 Sentinel 日志
tail -f /var/log/redis/sentinel.log

（6）客戶端配置示例

無需配置全部 Sentinel 地址：客戶端只需連接任意一個正常工作的 Sentinel 即可獲取集群狀態(tài)（Sentinel 之間通過 Gossip 協(xié)議自動同步信息）。

推薦配置多個 Sentinel 地址：僅用于容災，避免某個 Sentinel 不可用時客戶端無法初始化。

Set<String> sentinels = new HashSet<>();
sentinels.add("sentinel1:26379"); // 只需 1 個 Sentinel 即可工作
sentinels.add("sentinel2:26379"); // 額外添加用于容災
sentinels.add("sentinel3:26379"); // 非必須，但建議
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);

4. 特點

（1）高可用：Sentinel 確保主節(jié)點故障時自動切換。

（2）無分片：僅解決 HA 問題，不擴展寫性能。

（3）最少 3 節(jié)點：建議部署 3 個 Sentinel 以避免腦裂問題。

三、集群模式（Cluster）

1. 簡介

（1）整體設計：支持主從實現高可用，將數據分片到 16384 個槽（Slot），每個節(jié)點負責部分槽，已實現水平擴展。

（2）適用場景：大數據量、高并發(fā)、需要橫向擴展的場景。

2. 整體架構

組成部分：

（1）Master 節(jié)點（主節(jié)點）

• 負責處理客戶端讀寫請求。
• 管理分配的哈希槽（Slot）范圍（如 Slots 0-5460）。
• 通過 Gossip 協(xié)議 與其他節(jié)點交換集群狀態(tài)信息。

（2）Slave 節(jié)點（從節(jié)點）

• 異步復制對應 Master 的數據（通過 -->|Replication| 箭頭表示）。
• 當 Master 故障時，Slave 可自動晉升為新的 Master（故障轉移）。
• 可處理讀請求（需客戶端配置 READONLY）。

（3）通信協(xié)議

• 節(jié)點間通過 Gossip 協(xié)議（PING/PONG 消息）交換集群拓撲、槽分配、節(jié)點狀態(tài)等信息。

數據機制：

（1）哈希槽（Slots）分布

• Redis Cluster 將所有數據劃分為 16384 個槽位，每個 Master 負責一部分槽范圍（如 0-5460）。
• 客戶端通過 CRC16(key) mod 16384 計算鍵所屬的槽位。

（2）Move 重定向

• 若客戶端訪問的鍵不屬于當前連接的節(jié)點，節(jié)點會返回 MOVED 錯誤并指引正確節(jié)點。

3. 配置方法

（1）修改 redis.conf（每個節(jié)點）

bind 0.0.0.0
cluster-enabled yes               # 啟用集群模式
cluster-config-file nodes-6379.conf  # 集群節(jié)點配置文件
cluster-node-timeout 15000        # 節(jié)點超時時間（15 秒）
requirepass yourpassword          # 集群密碼
masterauth yourpassword           # 主節(jié)點間認證密碼

（2）啟動所有節(jié)點

redis-server /path/to/redis-6379.conf
redis-server /path/to/redis-6380.conf

（3）創(chuàng)建集群

# 6 個節(jié)點（3 主 3 從）
redis-cli --cluster create \
  127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 \
  127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 \
  # --cluster-replicas 1 表示每個主節(jié)點有 1 個從節(jié)點
  --cluster-replicas 1 -a yourpassword 

（4）驗證集群狀態(tài)

redis-cli -c -p 6379 -a yourpassword
127.0.0.1:6379> CLUSTER INFO
127.0.0.1:6379> CLUSTER NODES

（5）客戶端配置示例

支持集群協(xié)議：客戶端需實現 Redis Cluster 的 MOVED/ASK 重定向邏輯（主流客戶端庫已內置支持）。

種子節(jié)點配置：只需配置集群中任意 1-2 個節(jié)點地址（客戶端會自動發(fā)現其他節(jié)點）。

認證信息：若集群啟用密碼，需統(tǒng)一所有節(jié)點的密碼。

public class RedisClusterExample {
    public static void main(String[] args) {
        // 1. 配置至少一個集群節(jié)點地址（多個更容錯）
        Set<HostAndPort> nodes = new HashSet<>();
        nodes.add(new HostAndPort("127.0.0.1", 6379));
        nodes.add(new HostAndPort("127.0.0.1", 6380));
        // 2. 創(chuàng)建集群連接（帶密碼）
        JedisCluster jedisCluster = new JedisCluster(nodes, 2000, 2000, 5, "yourpassword");
        // 3. 執(zhí)行命令（自動處理重定向）
        jedisCluster.set("foo", "bar");
        String value = jedisCluster.get("foo");
        System.out.println(value); // 輸出 "bar"
        // 4. 關閉連接
        jedisCluster.close();
    }
}

4. 特點

（1）在 Redis Cluster 中，擴充主節(jié)點時，必須重新分配槽（Slots），這是由集群的分布式數據分片機制決定的。

（2）節(jié)點故障時，槽是否要重新分配，具體場景如下：

四、增強代理集群模式

上述三種部署模式特點如下：

在實際生產環(huán)境中，推薦采用 Redis 集群模式（Cluster）部署，以確保集群高可用（主從）與水平擴展（數據分片），但該模式存在客戶端配置繁瑣、無法兼容歷史配置等問題，所以官方推出了 Redis Cluster Proxy，旨在簡化客戶端與 Redis Cluster 的交互，它允許客戶端像連接單節(jié)點 Redis 一樣訪問 Redis Cluster，無需處理 MOVED/ASK 重定向和集群拓撲變更。

1. Redis Cluster Proxy 核心功能

（1）透明集群訪問

• 客戶端無需感知集群拓撲，Proxy 自動處理請求路由和重定向。
• 兼容標準 Redis 協(xié)議，支持所有單節(jié)點命令（除部分集群管理命令如 CLUSTER）。

（2）連接池管理

• 復用后端連接，減少客戶端與多個節(jié)點直接建連的開銷。

（3）協(xié)議兼容性

• 支持舊版 Redis 客戶端（如僅支持單節(jié)點模式的 SDK）。

（4）性能較好

• 基于 C 開發(fā)，性能損耗低（官方測試延遲增加約 10%）。

2. Redis Cluster Proxy 配置方法

(1) 安裝 Redis Cluster Proxy

# 從官方倉庫編譯安裝
git clone https://github.com/RedisLabs/redis-cluster-proxy.git
cd redis-cluster-proxy
make
./src/redis-cluster-proxy -c proxy.conf

(2) 配置文件 proxy.conf

# 綁定端口
bind 0.0.0.0
port 7777
# 后端 Redis Cluster 節(jié)點
cluster-node-timeout 5000
cluster 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003

(3) 啟動 Proxy

./src/redis-cluster-proxy -c proxy.conf

3. Redis Cluster Proxy 部署增強

實際部署 Proxy 時，為確保整個系統(tǒng)高可用，應部署多個 Proxy 實例，通過 HAProxy（或 LVS、Envoy）實現 Proxy 的高可用與水平擴展，整體架構如下：

負載均衡層：

（1）作用：

• 將請求分發(fā)到多個 Proxy 實例（輪詢/最小連接數）。
• 健康檢查自動剔除故障 Proxy。

（2）配置示例（以 HAProxy 為例）：

frontend redis-proxy
    bind *:6379
    mode tcp
    default_backend proxy_servers
backend proxy_servers
    mode tcp
    balance roundrobin
    server proxy1 192.168.1.100:7777 check inter 2s
    server proxy2 192.168.1.101:7777 check inter 2s

為保證 HAProxy 的高可用，我們一般會部署兩套 HAProxy，通過 Keepalived 互為主備，即增強代理集群，整體架構如下：

該集群具備 Redis Cluster 的高可用與水平擴展能力，以及 Redis Cluster Proxy 的透明訪問特性（兼容歷史配置，簡化客戶端調用）。此外，借助 Keepalived 和 HAProxy（或 LVS、Envoy），實現 Redis Cluster Proxy 節(jié)點及集群的高可用，同時簡化了集群調用代碼的配置復雜度。

五、總結與建議

哨兵模式不支持水平擴展，且與集群模式一樣，存在與客戶端配置代碼強耦合，難以兼容歷史配置，無法實現透明訪問等問題。因此在實際使用中，推薦采用 Keepalived + HAProxy（LVS 或 Envoy） + Redis Cluster Proxy + Redis Cluster 增強代理集群模式部署，以實現集群高可用、水平擴展、透明訪問及兼容歷史配置等必要功能。

到此這篇關于Redis 部署模式詳解的文章就介紹到這了,更多相關Redis 部署模式內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論