目录

主从复制

主从复制

作用

缺陷

主从复制流程

实现Redis主从复制

哨兵模式

主从复制切换的缺点

哨兵的核心功能

哨兵模式原理

哨兵模式的作用

哨兵结构组成

故障转移机制

主节点的选举

实现哨兵模式

集群(Cluster)

---

redis群集有三种模式，主从复制，哨兵模式，集群(Cluster)

主从复制

主从复制

主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

主从复制具体是指将一台redis服务器的数据，复制到其他的Redis服务器，前者称为主节点(master)，后者称为从节点(slave)，数据复制是单向的，只能由主节点到从节点。

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

作用

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

故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复

负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务，分担服务器负载，尤其是在写少读多的情况下，通过多个从节点分担读负载，可以大大提高Redsi服务器的并发量

高可用基石：主从复制是哨兵和集群能够实施的基础，是Redis高可用的基础

缺陷

故障无法自动化，写操作无法负载均衡，存储能力受到单机限制

主从复制流程

如果启动一个slave进程，则他会向master机器发送一个"sync command"命令，请求同步链接

无论是第一次连接还是重新连接，master机器都会启动一个后台进程，将数据快照保存到数据文件中(执行rdb操作)，同时master 还会记录修改数据的所有命令并缓存到数据文件中

后台进程完成缓存操作之后，master机器就会向slave机器发生数据文件，slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着master机器会将修改数据的所有操作一并发给slave机器，若slave机器出现故障宕机，则恢复故障后重新连接

master机器收到slave端机器的连接后，将其完整的数据文件发送给slave机器，如果master同时收到多个slave发来的同步请求，则master会在后台启动一个进程保存数据文件，然后将其发送给所有的slave端机器，确保所有的slave机器都正常

实现Redis主从复制

master:192.168.94.7

slave1:192.168.94.8

slave2:192.168.94.9

主配置

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持久化功能
 

vim /etc/redis/6379.conf

/etc/init.d/redis_6379 restart

从配置

两台从配置一样
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 192.168.94.7 6379     288行，指定要同步的Master节点IP和端口
appendonly yes                          700行，开启AOF持久化功能
vim /etc/redis/6379.conf

查看主从状态

测试

哨兵模式

主从复制切换的缺点

当服务器宕机后，需要手动一台从机切换为主机，这需要人工干预，不仅费时费力而且还会造成一段时间内服务不可用。

为了解决主从复制的缺点，就有了哨兵机制。

哨兵的核心功能

在主从复制的基础上，哨兵引入了主节点的自动故障转移

哨兵模式原理

哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。

哨兵模式的作用

监控：哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其它从节点改为复制新的主节点。

通知（提醒）：哨兵可以将故障转移的结果发送给客户端。

哨兵结构组成

哨兵节点和数据节点

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。

数据节点：主节点和从节点都是数据节点。

故障转移机制

1.由哨兵节点定期监控发现主节点是否出现了故障，每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了。

2.当主节点出现故障，此时哨兵节点会通过Raft算法（选举算法）实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。

3.由leader哨兵节点执行故障转移，过程如下：
将某一个从节点升级为新的主节点，让其它从节点指向新的主节点；
若原主节点恢复也变成从节点，并指向新的主节点；
通知客户端主节点已经更换。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

主节点的选举

1.过滤掉不健康的（已下线的），没有回复哨兵 ping 响应的从节点。
2.选择配置文件中从节点优先级配置最高的。（replica-priority，默认值为100）
3.选择复制偏移量最大，也就是复制最完整的从节点。

哨兵的启动依赖于主从复制，所以须把主从复制部署好的情况下再去做哨兵模式

实现哨兵模式

修改配置文件（主从修改内容一致）

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 192.168.94.7 6379 2    

84行，修改 指定该哨兵节点监控192.168.94.7:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移

sentinel down-after-milliseconds mymaster 30000    113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000        146行，故障节点的最大超时时间为180000（180秒）
vim /opt/redis-5.0.7/sentinel.conf

下面亮相皆为默认，默认即可

启动哨兵模式

注意：先启动主进程，再启动从进程

redis-sentinel sentinel &  启动哨兵

redis-cli -p 26379 info sentinel  查看哨兵的详细信息

测试

tailf /var/log/sentinel.log

将192.168.94.7恢复，并恢复成从

集群(Cluster)