redis主从复制丶哨兵模式丶集群模式

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader),后者称为从节点
(slave/follower);数据的复制是单向的，只能由主节点到从节点。Maste以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括

1、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量及效率。
2、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
3、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余。
4、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G ,也不能将所有内存用作Redis存储内存，
一般来说，单台Redis最大使用内存不应该超过20G.
电商网站上的商品，一般都是一次上传，无数次浏览的,说专业点也就是“多读少写，
对于这种场景，我们可以使如下这种架构：

主从复制环境配置

查看主机信息

我们这里只有一台服务器所以就只复制redis.conf通过启动不同的配置文件，来模拟多台机器，现实场景大家就可以在不同的服务器上都安装redis然后启动再配置即可。原理是一样的。

首先我们复制多份redis.conf

修改每个配置文件以redis80.conf为例：
1.bind监听的地址

2.端口号
3.开启后台启动

4.pid文件保存位置

5.日志文件保存位置

6.rbd文件保存位置

（修改文件保存位置，是为了防止文件被覆盖,如果redis在不同的服务器上，那么上面大部分配置都不用修改）
修改完成指定配置文件启动各个redis服务

redis -server /配置文件目录/redis6380.conf redis -server /配置文件目录/redis6381.conf redis -server /配置文件目录/redis6379.conf

主从复制绑定操作

方式1：命令绑定

slaveof ip prot 指定主节点redis所在的ip与端口

该方式配置主从关系后，假如从机宕机后，再启动那么从机丢失之前的主从关系，变成默认的主机，而主机宕机后依旧保持原来的主从关系。
方式2：通过配置文件

该方式配置的主从关系是永久的，就算从机宕机后恢复，那么它依然是从机。不会丢失主从关系。

主从测试：
主机插入数据

从机读取数据

从机插入数据会报错，默认从机只能读，不能写。可以在配置文件中开启非只读:slave-read-only no

主从复制的同步过程

1.从节点启动成功连接到主节点后会发送一个sync命令；
2.主节点接到sync命令后，启动一个子线程根据缓存中的数据生产一份持久化文件，同时收集所有接收到的用于修改数据集命令。
3.主节点的bgsave执行完成后，将持久化文件发送给从节点；从节点首先清除自己的旧数据，然后载入接收的持久化文件，将数据库状态更新至主节点执行bgsave时的数据库状态。
全量同步：根据主节点中的数据生产持久化文件，从节点执行持久化文件完成全量同步。（ps:从节点每次连接主节点都是一次全量同步）
增量同步：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；

宕机后的处理策略

（手动版反客为主）
1.如果主节点宕机，那么剩下的从节点是没办法写操作的，那么此时可通过执行slaveof no one命令，指定一台从节点转为主节点。来解决不能写的问题，然后再更改其它从节点指向6381为主节点即可

(ps：此时原来的6379就算恢复，那么手下也没有从节点了。)

哨兵模式

目的
哨兵模式就是为了，在主从复制模式下主节点发生问题时，自动选举新的主节点，自动修改主从配置，提高redis可用性。

概述
（自动版反客为主）

• Redis的主从复制模式下， 一旦主节点由于故障不能提供服务， 需要人工将从节点晋升为主节点， 同时还要通知其他从节点更新主节点地址， 对于很多应用场景这种故障处理的方式是无法接受的。于是redis从2.8开始正式提供了Redis Sentinel（哨兵） 架构来解决这个问题。
• 简单来说，哨兵模式其实就是自动版的反客为主，当主节点故障后，会自动投票在剩下的从节点中选择一个从节点晋升成主节点。
• 哨兵模式，每个哨兵都是一个独立的进程，哨兵会向被监控的主节点不断发送心跳验证来监测主节点是否正常运行。

哨兵模式的三个作用

• 监测：通过发送命令让redis服务器返回当前运行的状态
• 故障转移：当哨兵监测的主节点宕机，就会通过投票的方式自动选择一个从节点升级为主节点，然后通过发布订阅模式通知其他redis服务器，修改配置文件，重新认主节点。
• 通知：当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
  然而一个哨兵监控redis可能出现问题，因此可以引入哨兵集群
  

哨兵的工作方式

1. **持续监控：**每个哨兵节点会以每秒一次的频率，向所有被监控的主节点、从节点以及其他哨兵节点发送 PING 命令。
   – 通信方式：哨兵与 Redis 服务器建立 TCP 长连接，通过发送心跳包来检测对方是否存活。

2. **主观下线：**当一个哨兵节点在规定时间（由 down-after-milliseconds 配置项决定，默认30秒）内没有收到某个实例的有效 PONG 响应（或其他有效回复如 -LOADING），该哨兵就会独自将这个实例标记为“主观下线”。

3. **客观下线：**为了防止误判，它会通过 SENTINEL is-master-down-by-addr 命令向其他哨兵节点发起询问，集群中所有的哨兵都会向出问题的节点发生ping命令，当超过法定数量（Quorum） 的哨兵（该数量在配置文件中定义）都认为主节点下线时，主节点才会被标记为“客观下线”。
   – 达成共识：当超过法定数量（Quorum） 的哨兵（该数量在配置文件中定义）都认为主节点下线时，主节点才会被标记为“客观下线”。

4. 主节点被确认为客观下线后，哨兵集群需要选出一个“新的主节点”来执行后续的故障转移操作。这个选举过程基于 Raft 共识算法的变种实现。

开启哨兵

ps:开启哨兵前，首先要进行主从配置，只有这样哨兵在监视主节点时才会将从节点也纳入进来。
目前我们设置的是一主二从

1. 创建并修改哨兵的配置文件sentinel.conf，如果redis版本高的话，默认会有这个配置文件。
   

2. 配置监测节点（先配置最基本的，后面会有进阶配置）
   

sentinel monitor 节点名（随意起） redis节点地址 端口 投票权重

投票权重，如果主机宕机投票选举主节点时，如果权重为1，则相当于只能投一票。那个从节点得票最多，则晋升主节点。

3. 启动哨兵，进入redis bin目录里面有redis-sentinel

redis-sentinel 指定哨兵配置文件的位置

启动成功

测试哨兵模式

1.首先模拟主节点宕机，关闭6379

2.等待哨兵打印监测日志

根据上图，可看到6379发生了故障，然后执行故障转移到了6381，并且修改了6380与6379的主从配置，认6381为主节点。同时也会修改哨兵监测6381。
3.观察各机状态
6380

6381

6379

（此时6379已恢复状态，但已经成为6381的从节点了）

哨兵模式的优点

• 自动化的故障转移，主从可以自动切换。

哨兵模式配置详解

# Example sentinel.conf # 哨兵sentinel实例运行的端口 默认26379 port 26379 # 哨兵sentinel的工作目录 dir /tmp # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。 # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2 # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步， 这个数字越小，完成failover所需的时间就越长， 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster 1 # 故障转移的超时时间 failover-timeout 可以用在以下这些方面： #1. 同一个sentinel对同一个master两次failover之间的间隔时间。 #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了 # 默认三分钟 # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION #配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。 #对于脚本的运行结果有以下规则： #若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 #若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 #如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 #一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。 #通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本， 这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数， 一个是事件的类型， 一个是事件的描述。 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。 #通知脚本 # sentinel notification-script <master-name> <script-path> sentinel notification-script mymaster /var/redis/notify.sh # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。 # 以下参数将会在调用脚本时传给脚本: # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # 目前<state>总是“failover”, # <role>是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的 # 这个脚本应该是通用的，能被多次调用，不是针对性的。 # sentinel client-reconfig-script <master-name> <script-path> sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

哨兵模式与集群模式的核心区别

哨兵模式一主多从主要避免单点故障，集群模式多主多从，拥有更高的高可用丶高并发丶水平拓展的能力。

应用场景-哨兵模式：

1.适用于数据总量不超过单机内存。
2.读多写少的场景，一台主节点可以应对所有的改写操作，因为只有一个主节点可以进行改写操作，而且横向拓展多个主节点，如果要提升性能只能升级机器本身的配置提升有限。

应用场景-集群模式：

1.适用于海量的数据总量，单个机器的内存不够存储，需要通过哈希计算分片将数据分散到多个机器节点中拓展存储容量。
2.qps很高的情况下，单台主节点的改写操作成为性能瓶颈，需要多个主节点同时进行改写操作，且因为可以有多个主节点所以机器可以水平拓展。
（分片的原理，将所有主节点分成若干哈希槽（16384 ），然后通过哈希函数（CRC16 ）计算出哈希值，然后再对哈希槽的数量进行取模就能得到具体的分片槽位）
3.不支持多数据库： 集群模式下只能使用 db0。
4.集群模式下如果使用lua脚本，要保证传入的key的分片槽位要在同一节点中。可以通过{}号包裹相同的前缀，使其分配到同一节点中，被{}号修饰过的key，只会用{}内的内容进行分片计算。

核心区别对比表格

详细解释

1. Redis 哨兵模式

哨兵模式的核心是 “主从复制 + 哨兵机制”。

• 架构：

  • 一个主节点 负责处理所有写请求和部分读请求。

  • 一个或多个从节点 复制主节点的数据，负责读请求，起到负载均衡和备份的作用。

  • 一个哨兵集群 由多个哨兵进程组成，它们不存储数据，只负责监控所有Redis节点（主、从）的健康状况。当主节点宕机时，哨兵会自动将一个从节点提升为新的主节点，并让其他从节点复制新的主节点。同时，它会通知客户端新的主节点地址。

• 优点：

  • 高可用： 实现了自动化的故障转移，服务在主机宕机后能快速恢复。

  • 读负载均衡： 可以将读请求分发到多个从节点上。

  • 配置相对简单： 概念清晰，易于理解和部署。

• 缺点：

  • 写性能瓶颈： 所有写操作都集中在单个主节点，无法扩展写性能。

  • 存储瓶颈： 每个节点都存储全量数据，数据量受单机内存限制。

  • 故障转移期间数据丢失： 使用异步复制，在主节点宕机前未同步到从节点的数据会丢失。

2. Redis 集群模式
   集群模式的核心是 “数据分片 + 主从复制 + 高可用”。

• 架构：

  • 数据分片： Redis集群将整个数据集划分为16384个哈希槽。这些槽被分配给多个主节点。例如，一个3主节点的集群，可能分配为：Node1 (0-5460), Node2 (5461-10922), Node3 (10923-16383)。

  • 写入操作： 当客户端要写入一个键值对时，集群会对 key 进行 CRC16 校验并取模 16384，计算出它属于哪个哈希槽，然后将其存储到负责该槽的主节点上。这样，写压力就被分散到了多个主节点。

  • 主从复制： 每个主节点都有一个或多个从节点，同步其数据。

  • 高可用： 当某个主节点宕机时，它的从节点会自动被提升为新的主节点，继续服务它负责的那部分哈希槽。

• 优点：

  • 高性能： 读写请求可以分散到不同节点，真正实现了高性能的横向扩展。

  • 海量数据存储： 数据分片使得可以突破单机内存限制，存储超大规模数据。

  • 兼具高可用： 内置了类似哨兵的故障转移能力。

• 缺点：

  • 架构复杂： 部署和维护比哨兵模式复杂。

  • 客户端要求高： 客户端需要支持集群协议，能够正确处理重定向命令（如 -MOVED）。

  • 不支持多数据库： 集群模式下只能使用 db0。

  • 事务/Lua脚本限制： 涉及多个key的操作、事务和Lua脚本，必须确保所有这些key都位于同一个节点（即同一个哈希槽）。通常使用哈希标签 来强制将一组key映射到同一个槽。

如何选择？

• 选择哨兵模式当：

  • 你的数据量不大（在一台服务器内存范围内）。

  • 你的业务是读多写少，写操作的并发量还没有达到单台服务器无法处理的程度。

  • 你主要的需求是保证服务不中断，即高可用。

  • 你希望架构简单，易于管理。

• 选择集群模式当：

  • 你的数据量巨大，一台服务器内存根本装不下。

  • 你面临高并发读写，单台服务器已经成为性能瓶颈。

  • 你既需要高可用，又需要横向扩展性能和存储容量。

  • 你的团队有能力管理和维护更复杂的分布式系统。