Redis集群里怎么弄主从配置，简单实现数据同步和高可用方案

Redis实现数据同步和高可用，核心是依靠主从复制（Master-Slave Replication）技术，你可以把它想象成一个办公室的工作模式：有一个主管（主节点），一个或多个助手（从节点），主管负责处理所有重要的写操作（比如更新重要文件），而助手们的主要任务是备份主管处理过的所有内容，并且可以分担一些读文件（读操作）的请求，这样，即使主管突然请假（主节点宕机），也能立刻有一个助手顶上去,保证办公室不停摆。

主从配置与数据同步的简单实现

要让Redis实现主从配置，操作上出乎意料的简单，绝大多数配置都是在从节点上进行的,主节点几乎不需要做任何改动。

准备工作 假设你已经有两台或多台安装了Redis的服务器，一台我们指定为主节点（Master），IP地址是192.168.1.100；另一台为从节点（Slave），IP是192.168.1.101,Redis默认服务端口是6379。

配置从节点（关键步骤） 让一个Redis实例成为从节点,主要有两种方式：

• 修改配置文件（永久生效） 找到从节点服务器上的Redis配置文件 redis.conf，用文本编辑器打开它,找到以下配置行并进行修改：

  # replicaof <masterip> <masterport>

  将这行代码的注释符号 去掉,并填上主节点的IP和端口：

  replicaof 192.168.1.100 6379

  如果你给主节点设置了密码,还需要找到并修改下面这行：

  # masterauth <master-password>

  同样去掉注释,填上主节点的密码：

  masterauth your_master_password

  保存配置文件后，重启从节点的Redis服务，这样,从节点在每次启动时都会自动去连接指定的主节点并开始同步数据。

• 使用命令行（临时生效，重启失效） 你可以直接连接到从节点的Redis命令行界面（使用redis-cli）,然后执行一条命令：

  REPLICAOF 192.168.1.100 6379

  如果主节点有密码,还需要执行：

  CONFIG SET masterauth your_master_password

  这种方式会立即生效，从节点会开始同步数据，但缺点是当从节点重启后，这个配置会丢失，又变回一个独立的主节点,所以生产环境强烈推荐使用方式一。

验证主从状态 配置完成后，如何确认主从关系已经建立并且数据正在同步呢？ 你可以在主节点和从节点上分别执行 INFO replication 命令来查看状态。

在主节点上，你会看到类似这样的信息，其中connected_slaves显示连接上的从节点数量,下面会列出从节点的详细信息：

role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6379,state=online,offset=1234,lag=0
...

在从节点上，你会看到它明确了自己的角色是从节点,并显示了主节点的信息：

role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up  # 这个状态为up表示连接正常
...

数据同步的过程 一旦配置成功,数据同步会自动发生：

• 全量同步：当从节点第一次连接主节点，或者落后主节点数据太多时，主节点会创建一个当前数据的快照（RDB文件），发送给从节点，从节点清空自己的旧数据，然后加载这个RDB文件,将数据状态恢复到与主节点一致。
• 增量同步：全量同步完成后，主节点每执行一个写命令（如SET、DEL），都会把这个命令同时发送给所有从节点，从节点执行同样的命令，从而实时保持数据一致，这个过程中主节点会用一个叫“复制积压缓冲区”的区域来临时存储最近发出的命令,以防从节点短暂断线后丢失命令。

高可用方案：Sentinel（哨兵）

只有主从复制，还不能实现真正的高可用，因为如果主节点宕机了，虽然从节点有完整的数据备份，但它不会自动顶替上去成为新的主节点，客户端也无法自动知道现在应该向谁写入数据，这时，就需要一个“哨兵”机制来监控和自动故障转移。

Redis Sentinel（哨兵）就是这个角色，哨兵本身也是一个独立的Redis进程（不存储数据）,它的唯一任务就是监控主从集群的健康状况。

哨兵的工作方式

• 监控：你只需要配置哨兵去监控主节点（不需要监控从节点，哨兵能自动发现从节点），哨兵会定期向主节点、从节点以及其他哨兵发送心跳包,检查它们是否正常运行。
• 自动故障转移：当主节点被哨兵判定为“客观下线”（即多个哨兵实例都认为它失联了），哨兵们会自动投票选举出一个新的主节点（通常是从节点中数据最新的一个）。
• 通知客户端：故障转移完成后，哨兵会将新的主节点地址通知给客户端，这样,客户端就能自动重连到新的主节点上继续写作业。

简单配置哨兵 哨兵也需要一个配置文件，sentinel.conf,一个最简配置如下：

sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster your_master_password  # 如果主节点有密码

• sentinel monitor mymaster ... 2：告诉哨兵监控名为mymaster的主节点，地址是192.168.1.100:6379，最后的2是法定人数,表示至少需要2个哨兵同意才能判定主节点下线。
• down-after-milliseconds：设定一个超时时间（如5000毫秒），如果哨兵在这段时间内没收到主节点的响应，就认为它“主观下线”。
• failover-timeout：设定故障转移的超时时间。

启动哨兵 使用专门的命令启动哨兵进程：

redis-sentinel /path/to/sentinel.conf

为了高可用本身，哨兵也需要部署至少三个实例（最好分布在不同的物理机上）,以避免哨兵自己成为单点故障。

总结一下完整的高可用方案： 你搭建一个主从复制的Redis集群（一主两从），然后部署三个哨兵进程来监控这个集群，当主节点发生故障时，哨兵会自动从两个从节点中选举出新的主节点，并通知客户端切换连接，整个过程对应用程序是透明的，从而实现了Redis服务的高可用性，这个方案在保证数据不丢失和服务持续可用之间取得了很好的平衡,是Redis官方推荐的标准做法。

参考资料：此说明内容基于Redis官方文档中关于复制（Replication）和哨兵（Sentinel）的核心原理描述。