目录
Redis 高可用实现的方式有持久化、主从复制、哨兵、集群，与持久化不同，另外三种方式都是属于集群，之前已经分析了解过两种持久化模式了，现在了解另外几种方式
Redis 主从复制
Redis 主从复制简介
主从复制是哨兵和集群的基础，他们都是建立在主从复制的基础上实现高可用的。
主从复制将一台Redis 服务器的数据，复制到其他的 Redis 服务器来实现多机备份以及对于读操作的负载均衡和简单的故障恢复
和MySQL主从复制差不多，一台master 多台 slave ，数据是单向的，只能由主节点到从节点
Redis 主从复制的作用
数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
Redis 主从复制流程
1.启动 Slave 进程和发送 sync 命令：
当 Redis 从节点（Slave）启动并连接到主节点（Master）时，它会发送 SYNC 命令来请求数据同步。这是主从复制过程的开始
2.主节点处理同步请求：
主节点接收到 SYNC 请求后，会启动一个后台进程来执行数据快照操作。这一步称为 RDB 快照，它会将当前的内存数据保存到磁盘上的 RDB 文件中。在进行 RDB 快照的同时，主节点还会记录所有写操作到 AOF 文件（Append-Only File），如果启用了 AOF 持久化策略的话。
3.发送数据文件到从节点：
主节点完成数据快照后，会将 RDB 文件发送给从节点。接收数据文件的从节点会先将数据写入磁盘，然后再加载到内存中。同时，主节点会将之后的所有写操作通过增量同步（增量日志）的方式发送给从节点，这些操作会被应用到从节点上，以保持主从节点的数据一致性。
4.处理多个从节点的同步请求：
如果主节点同时接收到多个从节点的同步请求，它会启动一个后台进程来处理数据快照，并将 RDB 文件发送给所有的从节点。为了保证所有的从节点在同步时的一致性，主节点会在后台同时处理所有从节点的请求。
5.从节点故障恢复：
如果从节点出现故障并重新启动，它会重新连接主节点，并发起一个新的同步请求。主节点会按照上述流程重新向从节点发送数据快照和后续的增量操作。在发送过程中，主节点会将所有后续的写操作通过增量同步的方式分发给所有的从节点，以保证数据的一致性。
搭建Redis 主从复制
至少三台机器，一台master，两台slave
安装步骤省略，三台机器都默认安装 Redis
master节点
编辑Redis配置文件
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
appendonly yes #700行，开启AOF持久化功能
重启 Redis
/etc/init.d/redis_6379 restart
slave 节点
同样编辑Redis配置文件，两台slave 节点一样
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
replicaof 172.16.233.101 6379 #288行，指定要同步的Master节点IP和端口
appendonly yes #700行，开启AOF持久化功能
重启Redis
/etc/init.d/redis_6379 restart
验证
在Master节点上看日志：
tail -f /var/log/redis_6379.log
同步成功
哨兵
哨兵用于监控Redis主从复制集群中的主节点和从节点，并在主节点发生故障时进行故障转移，将一个从节点提升为新的主节点，即主从切换，主从切换就是，当服务器宕机后，将一台从机切换为主机，一般情况这需要人工干预，不仅费时费力而且还会造成一段时间内服务不可用。所以，为了解决主从复制的缺点，就有了哨兵机制，哨兵机制自动进行主从切换 。哨兵模式通过多个哨兵实例协同工作，确保Redis集群的高可用性和数据一致性。
所以，哨兵的核心功能就是在主从复制的基础上，设置了监控机制，引入了主节点的自动故障转移，并会转发通知
故障转移机制
那么哨兵是如何发现故障的呢？
哨兵系统由多个哨兵节点组成，主节点和从节点都称为数据节点，由哨兵节点定期向主节点以及其他哨兵节点发送心跳报文，如果主节点在一定时间内未回复，或者回复了错误内容，那么这个哨兵节点就会主观认为主节点宕机了，如果超过半数的哨兵主观的认为主节点宕机了，那么这个主节点就被确定为客观宕机了
当确定主节点宕机后，哨兵节点会通过选举机制，选举出一个哨兵节点作为leader，来负责处理主节点的故障转移通知，因此，哨兵的集群中至少得有三个哨兵节点
其中leader哨兵节点执行故障转移的过程分为几步
首先将一个从节点升级为新的主节点，让其他从节点指向新的主节点
假如原来的主节点恢复了，它依然不会再次变成主节点，而是指向新的主节点
最后通知客户端主节点更换
然后是选举机制，首先没有心跳的哨兵会过滤掉，然后根据配置文件中优先级的高低，选举出leader，或者根据复制偏移量的大小来选举
部署哨兵
所有哨兵节点都需进行操作
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no #17行，关闭保护模式
port 26379 #21行，Redis哨兵默认的监听端口
daemonize yes #26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log" #36行，指定日志存放路径
dir "/var/lib/redis/6379" #65行，指定数据库存放路径
sentinel monitor mymaster 172.16.233.101 2 #84行，该哨兵节点指定监控这个节点2是至少
需要2个哨兵节点同意才能进行故障转移
sentinel down-after-milliseconds mymaster 30000 #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #146行，故障节点的最大超时时间为180000（180秒）
启动哨兵模式
先启动master ，在启动slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
查看哨兵信息
redis-cli -p 26379 info Sentinel
Redis集群
集群都是大同小异的，由多个节点组成，不同的是Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。
作用
数据分区
这是 Redis 集群最核心的功能。通过将数据分散存储到多个节点上，解决了 Redis 单机内存的限制问题，从而大大增加了存储容量。这种分区使得 Redis 集群不仅能够扩展数据存储量，还能提高系统的性能和响应能力。因为每个主节点可以独立处理读写请求，整体集群的处理能力成倍提升。
高可用
Redis 集群通过主从复制机制以及自动故障转移功能，实现高可用性。当集群中任意节点发生故障时，其他节点可以接管工作，保证集群的持续运行。这个机制类似于 Redis 哨兵（Sentinel），能够自动检测并处理主节点的故障，使得系统对外服务不会中断。
Redis集群
和其他集群不同的是，Redis 集群定义了哈希槽。哈希槽是 Redis 集群用来实现数据分片的基本单元，Redis 集群总共定义了 16384 个哈希槽（0-16383），每个节点负责一部分哈希槽，也就是说，每个节点上会存储若干个哈希槽中的键值数据。根据计算得出哈希编号，那个key属于哪个哈希槽，通过这个值，会根据哈希槽和节点的对应关系，直接找到负责该哈希槽的节点
为每个节点添加一个从节点A1、B1、C1整个集群便有三个Master节点和三个slave节点组成，在节点B失败后，集群选举B1位为的主节点继续服务。当B和B1都失败后，集群将不可用。