Redis 集群的三种方式
Redis 集群提供了三种分布式方案：
主从模式 ：一个主节点和一个或多个从节点，主节点负责写操作，从节点负责读操作，实现读写分
离，分担主节点的压力。
哨兵模式 ：哨兵系统用于监控多个 Redis 服务器，当主服务器出现问题时，哨兵会自动进行故障迁
移，选举一个新的主服务器。
集群模式 ： Redis Cluster 通过将键空间分割为 16384 个槽位，每个主节点负责一部分槽位，实现数
据的分布式存储和高可用性。
每种方式的优缺点和适用场景
主从模式的优缺点 ：
优点 ：实现读写分离，分担主节点的压力。
缺点 ：当主节点宕机时，需要手动切换或等待重启，不具备自动故障恢复功能。
适用场景 ：适用于对数据一致性和高可用性要求不高的场景。
哨兵模式的优缺点 ：
优点 ：自动故障迁移，实现高可用性。
缺点 ：配置复杂，需要部署哨兵系统。
适用场景 ：适用于对高可用性有较高要求的场景。
集群模式的优缺点 ：
优点 ：高可用性、高扩展性、数据自动分片和复制。
缺点 ：配置复杂，需要多个节点协同工作。
适用场景 ：适用于大规模、高并发、高可用的场景。
**1.**主从复制
什么是主从复制
主从复制是将一台 Redis 服务器的数据复制到其他 Redis 服务器，前者叫 master/leader 主节点，后
者成为从节点 slave/follower ，数据库的复制是单项的，只能由主 --> 从， master 以写为主， slave
以读为主，利用主从复制实现读写分离，最低配的主从复制也需要一主二从。
主从复制中，从节点只能进行读操作，如果在从节点执行写命令则会报错，主节点可以执行读写操
作，但我们网网规定主节点只能进行写操作，这样也是符合了读写分离；默认情况下，每个 Redis
服务器都为主节点，即 master 。
主从复制的作用
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速故障恢复，实际上是一种服务
的冗余 - 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读，即写
redis 数据库时 app 连接主节点，读时连接从节点，分担服务器压力，尤其是写少读多场景下，通
过多个从节点分担读的流量，可以大大提高 redis 服务器并发量 - 高可用基石：主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 redis 高可用的基础
Redis 主从复制搭建（一主二从）
分别命名 6379 、 6380 、 6381 ，以 6379 为主机
主库 6379 （ master ），从库 6380(slave ）， 6381(slave ）修改 redis.windows.conf 下端口号
修改 dump.rdb ，该文件是 redis 的 RDB 方式持久化生成的数据文件
注意，三个文件都要改
修改从库 redis.windows.conf
slaveof 主库 IP 主库端口号
masterauth 主库密码
启动主库，在启动从库，进行测试，主库添加数据，从库同步
进入主库，使用命令： info replication 查看是否主从复制
复制的过程原理
1 、 当从库和主库建立 MS 关系后，会向主数据库发送 SYNC 命令；
2 、 主库接收到 SYNC 命令后会开始在后台保存快照（ RDB 持久化过程），并将期间接收到的写命令缓
存起来；
3 、 当快照完成后，主 Redis 会将快照文件和所有缓存的写命令发送给从 Redis ；
4 、 从 Redis 接收到后，会载入快照文件并且执行收到的缓存的命令；
5 、 之后，主 Redis 每当接收到写命令时就会将命令发送从 Redis ，从而保证数据的一致；
无磁盘复制
通过前面的复制过程我们了解到，主库接收到 SYNC 的命令时会执行 RDB 过程，即使在配置文件中禁用
RDB 持久化也会生成，那么如果主库所在的服务器磁盘 IO 性能较差，那么这个复制过程就会出现瓶颈，
庆幸的是， Redis 在 2.8.18 版本开始实现了无磁盘复制功能（不过该功能还是处于试验阶段）。
原理：
Redis 在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接通过网络发送给从数据库，
避免了 IO 性能差问题。
开启无磁盘复制： repl-diskless-sync yes
复制架构中出现宕机情况，怎么办 ?
如果在主从复制架构中出现宕机的情况，需要分情况看：
1 、 从 Redis 宕机
a) 这个相对而言比较简单，在 Redis 中从库重新启动后会自动加入到主从架构中，自动完成同步数
据；
b) 问题？ 如果从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将所有的数据做
RDB 操作吗？还是增量更新？（从库有做持久化的前提下）
i. 不会的，因为在 Redis2.8 版本后就实现了，主从断线后恢复的情况下实现增量复制。
2 、 主 Redis 宕机
a) 这个相对而言就会复杂一些，需要以下 2 步才能完成
i. 第一步，在从数据库中执行 SLAVEOF NO ONE 命令，断开主从关系并且提升为主库继续服务；
ii. 第二步，将主库重新启动后，执行 SLAVEOF 命令，将其设置为其他库的从库，这时数据就能更新
回来；
b) 这个手动完成恢复的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，
Redis 提高的哨兵（ sentinel ）的功能。
**2.**哨兵
什么是哨兵
哨兵的作用就是对 Redis 的系统的运行情况的监控，它是一个独立进程。它的功能有 2 个：
1 、 监控主数据库和从数据库是否运行正常；
2 、 主数据出现故障后自动将从数据库转化为主数据库；
哨兵模式就是我们常讲的主从切换技术了，在哨兵模式没出来前，当我们的主服务器宕机了之后，需要
人为的去将从机切换成主机去顶一下，在从机中输入命令： slaveof no one , 让 从机 篡位 成为 主机，
而主从机的区别就是主机能 " 写、读 " ，而从机只能 " 读 " ，而人为干预主从切换会造成一段时间内服务不
可以使用的问题，于是在 Redis2.8 之后正式的提供了 Sentinel （哨兵模式）架构来解决这个问题，所以
哨兵模式也可以理解为：当 某门派大佬驾崩的时候，根据门派内的投票数直接让新老大上位
哨兵模式是一个独立的进程，做为进程，它会独立运行，原理就是通过发送命令，等待 Redis 服务器响
应，从而监控运行的多个 Redis 主从机
这个时候大家会想，如果在老大没了的时候，哨兵也没了咋整啊？整不下去了啊
一般来说，哨兵是不会出现事故的，那万一出现事故了呢？为了以防万一，那就再配一个哨兵的集群，
让他们相互试探有没有挂掉，如果集群里的哨兵都挂了，那么恭喜你 · ，可以去买彩票了
单个哨兵的架构
多个哨兵的架构
多个哨兵，不仅同时监控主从数据库，而且哨兵之间互为监控。
哨兵搭建（一主二从三哨兵）
在每个 redis 文件夹下创建 sentinel.conf 文件配置哨兵信息
编写配置信息
哨兵 sentinel 实例运行的端口 默认 26379
port 26379
本地 ip
bind 127.0.0.1
哨兵监听的主服务器 后面的 1 表示主机挂掉以后进行投票，只需要 2 票就可以从机变主机
sentinel monitor mymaster 127.0.0.1 6379 2
设置未得到主机响应时间，此处代表 5 秒未响应视为宕机
sentinel down-after-milliseconds mymaster 5000
设置等待主机活动时间，此处代表 5 秒主机未活动，则重新选举主机
sentinel failover-timeout mymaster 5000
设置主机的密码（无密码可以省略）
sentinel auth-pass mymaster 123456
设置重新选举主机后，同一时间同步数据的从机数量，此处代表重新选举主机后，每次 2 台从机同#步主机数
#据，直到所从
机同步结束
sentinel config-epoch mymaster 2
执行故障转移时， 最多有 2 个从服务器同时对新的主服务器进行同步
sentinel leader-epoch mymaster 2
注意：
三个都需要修改 port 分别是 26379 ， 26380 ， 26381
sentinel monitor mymaster 127.0.0.1 6379 2 端口号 6379 不需要修改 三个文件都一样
在每个 redis 文件夹下创建 startup_sentinel.bat 文件用于运行 sentinel.conf
记事本打开 bat 文件文件，写入内容 redis - server.exe sentinel.conf -- sentinel
运行 redis 三个服务，并使用命令检查是否主从复制 info replication
注意先启动主，在启动从
在启动 startup_sentinel.bat 三个都要启动
哨兵测试
从机宕机
使用命令 shutdown 关闭一个从机（或直接关闭）
80 宕机
