Redis 6.x 主从和哨兵

SunnyFan大约 18 分钟约 5503 字

Redis 6.x 主从和哨兵

2、主从复制(读写分离)

1、概念

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称之为主节点（master/leader），后者称之为从节点（slave/flower）；数据的复制都是单向的，只能从主节点到从节点。Master 以写为主，Slave 以读为主。

默认情况下，每台 Redis 服务器都是主节点。且一个主节点可以有多个从节点或者没有从节点，但是一个从节点只能有一个主节点。

2、主从复制的作用

1、数据冗余：主从复制实现了数据的热备份，是持久化的之外的一种数据冗余方式。

2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。实际也是一种服务的冗余。

3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读 Redis 的时候应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个节点分担读负载，可以大大提高 Redis 服务器的并发量。

4、高可用（集群）的基石：除了上述作用以外，主从复制还是哨兵模式和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

一般来说，要将Redis 运用于工程项目中，只使用一台 Redis 是万万不能的（可能会宕机），原因如下：

1、从结构上，单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力很大；

2、从容量上，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 265G，也不能将所有的内存用作 Redis 存储内存，一般来说，**单台 Redis最大使用内存不应该超过 20G**。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点就是“多读少写”。

对于这种场景，我们可以使用如下这种架构：

主从复制，读写分离！80% 的情况下，都是在进行读操作。这种架构可以减少服务器压力，经常使用实际生产环境中，最少是“一主二从”的配置。真实环境中不可能使用单机 Redis。

3、环境配置

只配置从库，不用配置主库。

[root@itzhouc bin]# redis-cli -p 6379
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> info replication			# 查看当前库的信息
# Replication
role:master									# 角色
connected_slaves:0							# 当前没有从库
master_replid:2467dd9bd1c252ce80df280c925187b3417055ad
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>

复制 3 个配置文件，然后修改对应的信息

1、端口

2、pid 名称

3、log 文件名称

4、dump.rdb 名称

port 6381
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump6381.rdb

修改完毕后，启动我们的 3 个 redis 服务器，可以通过进程信息查询。

[root@itzhouc ~]# ps -ef|grep redis
root       426     1  0 16:53 ?        00:00:00 redis-server *:6379
root       446     1  0 16:54 ?        00:00:00 redis-server *:6380
root       457     1  0 16:54 ?        00:00:00 redis-server *:6381
root       464   304  0 16:54 pts/3    00:00:00 grep --color=auto redis

5、几个问题

1、主机可以写，从机不能写只能读。主机中的所有信息和数据都会保存在从机中。如果从机尝试进行写操作就会报错。

127.0.0.1:6381> get k1			# k1的值是在主机中写入的，从机中可以读取到。
"v1"
127.0.0.1:6381> set k2 v2			# 从机尝试写操作，报错了
(error) READONLY You can't write against a read only replica.
127.0.0.1:6381>

2、如果主机断开了，从机依然链接到主机，可以进行读操作，但是还是没有写操作。这个时候，主机如果恢复了，从机依然可以直接从主机同步信息。

3、使用命令行配置的主从机，如果从机重启了，就会变回主机。如果再通过命令变回从机的话，立马就可以从主机中获取值。这是复制原理决定的。

6、主从工作原理

如果我们给master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC命令给master请求复制数据。
master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。
当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。

8、增量复制

这个缓冲默认1m , 在redis.conf中对应 repl-backlog-size 1mb

从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。

master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。

如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

3、哨兵模式（Sentinel）

sdown 主观下线 (哨兵认为你下线)
odown 客观下线（很多个哨兵都认为线下）【master选举】

1、概述

主从切换技术的方式是：当主机服务器宕机之后，需要手动将一台服务器切换为主服务器，这需要人工干预，费时费力，还会造成一段时间内的服务不可用。这不是一种推荐的方式，更多的时候我们优先考虑的的是哨兵模式。Redis 从 2.8 开始正式提供了 Sentinel（哨兵）架构来解决这个问题。

哨兵模式能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它独立运行。其原理是**哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例**。

这里的哨兵有两个作用

通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器
当哨兵检测到 master 宕机，会自动将 slave 切换为 master，然后通过发布订阅模式通知其他的从放服务器，修改配置文件，让他们切换主机。

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现单点故障问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机了，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵 1 主观认为主服务器不可用，这个现象称之为**主观下线**。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 【故障转移】。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称之为**客观下线**。

2、配置一个一主二从的哨兵模式

1、配置哨兵模式配置文件，新建文件 /usr/local/bin/kconfig/sentinel.conf。

# sentinel monitor 被监控的名字（随便写） host 1
sentinel monitor myredis 127.0.0.1 6379 1

后面的数字1代表主机宕机后，slave投票决定谁成为新的主机，票数最多成为主机。

2、启动哨兵

[root@itzhouc bin]# ls
6379.log  6381.log      dump6380.rdb  dump.rdb  redis-benchmark  redis-check-rdb  redis-sentinel
6380.log  dump6379.rdb  dump6381.rdb  kconfig   redis-check-aof  redis-cli        redis-server
[root@itzhouc bin]# redis-sentinel kconfig/sentinel.conf 
2421:X 15 May 2020 20:24:06.847 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2421:X 15 May 2020 20:24:06.847 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=2421, just started
2421:X 15 May 2020 20:24:06.847 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 5.0.5 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 2421
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

2421:X 15 May 2020 20:24:06.848 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2421:X 15 May 2020 20:24:06.851 # Sentinel ID is 100430af0018d23bd1ae2fe57e71e0d45f64d9a5
2421:X 15 May 2020 20:24:06.851 # +monitor master myredis 127.0.0.1 6379 quorum 1
2421:X 15 May 2020 20:24:06.852 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379

启动成功~！

如果现在 Master 节点宕机了，这个时候会从从机中根据投票算法选择一个作为主机。

如果原来的主机恢复运行了，只能归到新的主机下，作为从机，这就是哨兵模式的规则。

3、哨兵集群构建

1、编写3个sentinel.conf配置文件内容如下:

标准配置

#当前Sentinel服务运行的端口
port 26379  
# 哨兵监听的主服务器 
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover  
sentinel failover-timeout mymaster 10000  
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

# sentinel-26379.conf
port 26379
sentinel monitor myredis 192.168.3.240 6380 2
# sentinel auth-pass myredis redis设置的密码
# sentinel-26380.conf
port 26380
sentinel monitor myredis 192.168.3.240 6380 2
# sentinel-26381.conf
port 26381
sentinel monitor myredis 192.168.3.240 6380 2

2、启动3个哨兵

./redis-sentinel ./sentinel-26379.conf&
./redis-sentinel ./sentinel-26380.conf&
./redis-sentinel ./sentinel-26381.conf&

4.哨兵模式的优点

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有

2、主从可以切换，故障可以转移，系统的可用性就会更好

3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

Docker 部署 Redis 主从哨兵

使用 Docker Compose 部署

version: "3.8"
services:
  redis-master:
    image: redis:7-alpine
    container_name: redis-master
    command: redis-server --requirepass RedisPass123 \
      --masterauth RedisPass123 \
      --appendonly yes \
      --maxmemory 512mb \
      --maxmemory-policy allkeys-lru
    ports:
      - "6379:6379"
    volumes:
      - redis-master-data:/data
    restart: always
    networks:
      - redis-net

  redis-slave1:
    image: redis:7-alpine
    container_name: redis-slave1
    command: redis-server --requirepass RedisPass123 \
      --masterauth RedisPass123 \
      --replicaof redis-master 6379 \
      --appendonly yes
    ports:
      - "6380:6379"
    volumes:
      - redis-slave1-data:/data
    restart: always
    depends_on:
      - redis-master
    networks:
      - redis-net

  redis-slave2:
    image: redis:7-alpine
    container_name: redis-slave2
    command: redis-server --requirepass RedisPass123 \
      --masterauth RedisPass123 \
      --replicaof redis-master 6379 \
      --appendonly yes
    ports:
      - "6381:6379"
    volumes:
      - redis-slave2-data:/data
    restart: always
    depends_on:
      - redis-master
    networks:
      - redis-net

  redis-sentinel1:
    image: redis:7-alpine
    container_name: redis-sentinel1
    command: redis-sentinel /etc/sentinel/sentinel.conf
    ports:
      - "26379:26379"
    volumes:
      - ./sentinel1.conf:/etc/sentinel/sentinel.conf
    depends_on:
      - redis-master
    networks:
      - redis-net

  redis-sentinel2:
    image: redis:7-alpine
    container_name: redis-sentinel2
    command: redis-sentinel /etc/sentinel/sentinel.conf
    ports:
      - "26380:26379"
    volumes:
      - ./sentinel2.conf:/etc/sentinel/sentinel.conf
    depends_on:
      - redis-master
    networks:
      - redis-net

  redis-sentinel3:
    image: redis:7-alpine
    container_name: redis-sentinel3
    command: redis-sentinel /etc/sentinel/sentinel.conf
    ports:
      - "26381:26379"
    volumes:
      - ./sentinel3.conf:/etc/sentinel/sentinel.conf
    depends_on:
      - redis-master
    networks:
      - redis-net

volumes:
  redis-master-data:
  redis-slave1-data:
  redis-slave2-data:

networks:
  redis-net:
    driver: bridge

Sentinel 配置文件

# sentinel1.conf
port 26379
sentinel monitor myredis redis-master 6379 2
sentinel auth-pass myredis RedisPass123
sentinel down-after-milliseconds myredis 5000
sentinel failover-timeout myredis 60000
sentinel parallel-syncs myredis 1

# sentinel2.conf
port 26379
sentinel monitor myredis redis-master 6379 2
sentinel auth-pass myredis RedisPass123
sentinel down-after-milliseconds myredis 5000
sentinel failover-timeout myredis 60000
sentinel parallel-syncs myredis 1

# sentinel3.conf
port 26379
sentinel monitor myredis redis-master 6379 2
sentinel auth-pass myredis RedisPass123
sentinel down-after-milliseconds myredis 5000
sentinel failover-timeout myredis 60000
sentinel parallel-syncs myredis 1

验证主从与哨兵

# 启动
docker-compose up -d

# 查看主从复制状态
docker exec redis-master redis-cli -a RedisPass123 info replication

# 查看哨兵状态
docker exec redis-sentinel1 redis-cli -p 26379 info sentinel

# 测试写入（主节点）
docker exec redis-master redis-cli -a RedisPass123 set testkey hello
docker exec redis-slave1 redis-cli -a RedisPass123 get testkey

# 模拟主节点故障
docker stop redis-master
# 等待几秒后观察哨兵日志
docker logs redis-sentinel1 --tail 20

# 查看新的主节点
docker exec redis-sentinel1 redis-cli -p 26379 sentinel get-master-addr-by-name myredis

# 恢复原主节点（自动变为从节点）
docker start redis-master
docker exec redis-master redis-cli -a RedisPass123 info replication

哨兵模式生产配置详解

哨兵核心参数说明

# sentinel.conf 完整生产配置示例

# 哨兵监听的端口
port 26379

# 守护进程模式运行
daemonize yes

# PID 文件
pidfile /var/run/redis-sentinel.pid

# 日志文件
logfile /var/log/redis/sentinel.log

# 监控的主节点名称、IP、端口、quorum
# quorum 表示至少需要多少个哨兵同意主节点不可用才执行故障转移
sentinel monitor mymaster 192.168.1.100 6379 2

# 主节点密码
sentinel auth-pass mymaster MyStr0ngP@ss

# 主观下线时间（毫秒）
# 超过此时间未收到 PING 回复，哨兵主观认为主节点下线
sentinel down-after-milliseconds mymaster 5000

# 故障转移超时时间（毫秒）
# 包括选出新主节点、同步从节点等整个过程的超时
sentinel failover-timeout mymaster 60000

# 同时可以有几个从节点与新的主节点同步
# 值越小，故障转移完成越快，但同步期间从节点不可用
# 值越大，从节点同时不可用的越少，但故障转移越慢
sentinel parallel-syncs mymaster 1

# 通知脚本（可选）
# 主节点发生变化时执行
sentinel notification-script mymaster /etc/redis/notify.sh

# 故障转移后执行的脚本（可选）
sentinel client-reconfig-script mymaster /etc/redis/reconfig.sh

通知脚本示例

#!/bin/bash
# /etc/redis/notify.sh
# 参数：$1=事件类型 $2=主节点名称 $3=IP $4=端口

EVENT=$1
MASTER=$2
IP=$3
PORT=$4

echo "$(date) - 事件: $EVENT, 主节点: $MASTER, IP: $IP, 端口: $PORT" >> /var/log/redis/sentinel-events.log

# 发送告警（示例）
if [ "$EVENT" = "+sdown" ] || [ "$EVENT" = "+odown" ] || [ "$EVENT" = "+switch-master" ]; then
    # 调用告警接口或发送邮件
    curl -s -X POST "https://alerts.example.com/api/notify" \
        -d "{\"event\":\"$EVENT\",\"master\":\"$MASTER\",\"ip\":\"$IP\",\"port\":\"$PORT\"}" \
        -H "Content-Type: application/json"
fi

Redis 主从复制常见问题

复制延迟问题

# 查看复制延迟
redis-cli -a password info replication | grep lag
# slave0:ip=...,offset=...,lag=0

# 原因与解决：
# 1. 网络延迟 — 优化网络，减少跨机房复制
# 2. 大 Key 操作 — 避免单个 Key 超过 10MB
# 3. 从节点负载高 — 检查慢查询日志

# 查看慢查询
redis-cli -a password slowlog get 10

# 配置慢查询阈值
config set slowlog-log-slower-than 10000  # 10ms
config set slowlog-max-len 128

主从数据不一致

# Redis 复制是异步的，从节点可能短暂落后于主节点
# 检查复制偏移量差异
redis-cli -a password info replication | grep master_repl_offset

# 对于强一致性要求高的场景：
# 1. 使用 WAIT 命令（Redis 3.0+）等待复制确认
redis-cli -a password SET key value
redis-cli -a password WAIT 1 1000  # 等待至少 1 个从节点确认，超时 1000ms

# 2. 在写入关键数据后，短暂读取主节点
# 3. 使用 Redis Cluster 替代主从模式

复制缓冲区溢出

# 如果主从断开时间过长，复制缓冲区溢出会导致全量同步
# 增大复制缓冲区（在 redis.conf 中）
repl-backlog-size 64mb      # 默认 1MB，建议 32MB-256MB
repl-backlog-ttl 3600       # 缓冲区保留时间（秒）

# 监控复制状态
redis-cli -a password info replication
# 关注 master_repl_offset 和 slave_repl_offset 的差距

Redis 性能优化

内存管理

# 内存使用限制
maxmemory 2gb

# 淘汰策略
maxmemory-policy allkeys-lru
# allkeys-lru      — 淘汰最久未使用的 Key（适合缓存场景）
# allkeys-lfu      — 淘汰使用频率最低的 Key（Redis 4.0+）
# volatile-lru     — 只淘汰设置了过期时间的 Key
# volatile-ttl     — 淘汰即将过期的 Key
# allkeys-random   — 随机淘汰
# noeviction       — 不淘汰，写入时返回错误（默认）

# 查看内存使用情况
redis-cli -a password info memory
redis-cli -a password memory usage mykey    # 查看单个 Key 占用

# 查看大 Key
redis-cli -a password --bigkeys

# 采样分析内存
redis-cli -a password memory stats

连接管理

# 最大客户端连接数
maxclients 10000

# TCP keepalive
tcp-keepalive 300

# 超时设置
timeout 0              # 0 表示不超时（客户端空闲不断开）
# 生产环境建议设为 300（5分钟）

# 查看当前连接
redis-cli -a password client list
redis-cli -a password info clients

4、附录：

批量删除进程

ps -ef|grep redis|grep -v grep|awk ‘{print “kill -9 ” $2}’ |sh

关键知识点

部署类主题的核心不是“装成功”，而是“稳定运行、可排障、可回滚”。
同一个服务通常至少要关注版本、目录、端口、权限、数据、日志和备份。
Linux 问题经常跨越系统层、网络层、服务层和应用层。
缓存与开关类主题都在处理“配置/数据与运行时行为之间的解耦”。

项目落地视角

把安装步骤补成可重复执行的清单，必要时写成脚本或配置文件。
把配置目录、数据目录、日志目录和挂载点明确拆开。
上线前检查防火墙、SELinux、时区、磁盘、系统服务和健康检查。
明确 Key 设计、过期策略、回源逻辑和降级方案。

常见误区

使用 latest 或未固定版本，导致环境不可复现。
只验证启动成功，不验证持久化、开机自启和故障恢复。
遇到问题先改配置而不是先看日志和依赖链路。
只加缓存，不设计失效与一致性策略。

进阶路线

继续补齐 systemd、性能监控、安全加固和备份恢复。
把单机操作升级成 Docker、Kubernetes 或 IaC 方案。
建立标准化运维手册，包括巡检、扩容、回滚和灾备演练。
继续补齐多级缓存、缓存预热、分布式缓存治理和旗标管理平台。

适用场景

当你准备把《Redis 6.x 主从和哨兵》真正落到项目里时，最适合先在一个独立模块或最小样例里验证关键路径。
适合单机环境初始化、中间件快速搭建、测试环境验证和生产部署前准备。
当服务稳定性依赖端口、权限、目录、网络和系统参数时，这类主题会直接影响成败。

落地建议

固定版本号与镜像标签，避免“latest”带来的不可预期变化。
把配置、数据、日志目录拆开管理，并记录恢复步骤。
上线前确认端口、防火墙、SELinux、时区和磁盘空间。

排错清单

先查 systemctl、容器日志和应用日志，确认失败发生在哪一层。
检查端口占用、目录权限、挂载路径和网络连通性。
如果是新环境问题，优先对比与已知正常环境的差异。

复盘问题

如果把《Redis 6.x 主从和哨兵》放进你的当前项目，最先要验证的输入、输出和失败路径分别是什么？
《Redis 6.x 主从和哨兵》最容易在什么规模、什么边界条件下暴露问题？你会用什么指标或日志去确认？
相比默认实现或替代方案，采用《Redis 6.x 主从和哨兵》最大的收益和代价分别是什么？