Redis集群（五）
1. 主从复制
1.1. 作用
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
- 负载均衡：在主从复制的基础上配个读写分离，可以由主节点负责写操作，从节点提供读操作，从而分担服务器的负载，通过多个节点的负载分担可以大大提高Redis服务器的并发量。
- 高可用：主从复制是哨兵模式和集群能够实施的基础，因为主从复制是Redis高可用必不可少的一环。
1.2. 解决的问题
- 解决了单个Redis服务器会发生的单点故障问题。一般采用一主三从的方式解决宕机问题。
- 从容量来说，单台Redis服务器内存容量有限，一般来说Redis最大使用内存应该不要超过20G。
2. 集群配置（redis.conf）
Redis默认就是主库，所有配置主从时我们只需要配置从库就行了
2.1. 常用命令
# 查看当前redis库的集群配置信息：
# 1.role(主库还是从库)
# 2.connected_slaves 连接从库的数量
# 3.salve0：从机相关配置
# 4.其它配置项
info replication
# 从机配置主机主从复制
slaveof 主机ip 主机端口
2.2. 单台linux服务器配置集群
第一步
配置三台从机只需要复制2个redis.conf文件并重命名（如redis6380.conf redis6381.conf），然后修改响应的配置文件信息即可（当前多台Redis服务器配置可以根据具体业务进行配置文件的更改）：
- 更改端口（port）：如port = 6380
- pid名字
- log文件名字
- dump.rdb名字
第二步
开启四台Redis服务器以后，配置2台从机slaveof主机
-
命令方式：
# 给当前从机配置主机;此命令生效后该服务器role就是slave了 slaveof 主机ip 主机端口 -
配置文件方式（推荐）：直接在redis.conf文件中配置
# 配置文件中配置主机 slaveof <masterip> <masterport> -
命令和配置文件的区别：
# 配置文件配置的主从关系是永久的 # 命令的主从关系是暂时的 # 举例： # 命令行方式：如果从机宕机了，主机有新的写数据操作，过一段时间从机恢复了，这些新写的数据不会同步到这个从机。因为当前从机默认就是一台新的主机了，与原先的主机已经没有了主从关系。 # 配置文件方式: 如果从机宕机了，主机有新的写数据操作，过一段时间从机恢复了，这些新写的数据会同步到当前从机上面。因为配置文件配置的主从关系是永久的，当从机重启的那一刻主从关系就建立了。
#### 2.3. 主从复制的原理
1. slave启动成功连接到master后会向master发送一个sync同步命令。
2. master接收到命令之后，会启动后台的存盘进行，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，完成一次完全同步（全量复制）。
3. 全量复制：slave在接收到数据库文件数据后，将其存盘并加载到内存中
4. 增量服务：连接稳定建立之后，后续master会将新的收集到的修改数据的命令依次传递给slave，完成新数据的同步。
## 3. 哨兵模式
#### 3.1. 主机宕机解决方案
主机宕机之后，我们需要手动选择一个从机并将其设置为新的主机，一般使用slaveof no one命令或者直接更改从机的配置文件将当前从机更改为主机，然后其它的从机配置slaveof 新的主机，当原来旧的主机恢复以后，旧主机也不会有从机了。
手动的缺点：需要等待一定的时间来重新配置集群，生产环境不允许
#### 3.2. 哨兵模式解决宕机
当主机宕机之后，哨兵会自动在剩下的从机中选举出一个主机，重新建立新的主从集群，整个过程都是自动的，不会造成长时间的redis服务不可用，生产环境推荐。
如果多了一段时间旧主机恢复以后，旧主机就是一个单机模式了，不会再有从机slaveof。一般主机恢复服务以后，我们可以让他slaveof新主机，成为新集群中的一个从节点。
#### 3.3. 哨兵模式原理
哨兵其实就是一个独立的进程，作为进程，它会独立的运行。其监控原理就是定时的发送命令到集群中的redis服务器并等待响应，从而对多个运行的redis实例进行监控。
哨兵检测到master服务宕机以后，会自动将一个slave服务器切换为master，然后通过**发布订阅模式**通知其它的从服务器告诉它们需要更换主机了。
一般会配置多台哨兵进行集群监控，这样可以实现哨兵的高可用。如果三个哨兵都检测到master不可用，这时候哨兵就会投票决定mater宕机了（**主观下线**），然后进行failover故障转移操作。切换成功后，就会通过发布订阅模式通知各个哨兵进行选举出一个从机切换为新的主机，这个过程称为**客观下线**。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z9sHYeFA-1665930718265)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1648733747912.png)]
#### 3.4. 如何开启哨兵模式
1. 编辑sentinel.conf
```bash
# sentinel monitor 被监控节点名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
# 后面的数字1表示的是：如果主机挂了，Slave投票看谁成为新主机，票数最多的就会成为主机，这个1就相当于一个是主机的标志。
- 启动哨兵
# redis-sentinel 是启动哨兵的工具
redis-sentinel sentinel.conf
3.5. 哨兵进程日志
3.6. 优缺点
优点：
- 哨兵集群，基于主从复制模式，所有的主从配置的优点，它都有。
- 主从可以切换，故障可以转移，系统的可用性就会更好。
- 哨兵模式就是主从模式的升级版，从收到到自动，更加健壮。
缺点：
- Redis不好在线扩容，集群容量一旦达到上限，在线扩容就会十分麻烦。
- 实现哨兵模式的配置比较麻烦，并且其中有很多选项。
3.7. 配置文件（sentinel.conf）
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认是26379，如果有哨兵集群，我们还需要配置每个哨兵端口
port 26379
#哨兵sentinel的工作目录
dir /tmp
#哨兵 sentine1 监控的redis主节点的 ip port
# master-name ，可以自己命名的主节点名字 只能由字母A-Z、数字0-9、这三个字符" . - _ "组成。
# quorum配置多少个sentine1哨兵统- -认为master主节点失联那么这时客观上认为主节点失联了
# sentinel monitor 被监控节点名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
#当在Redis实例中开启了requirepass foobared 授权密码这样所有连接kedis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置- - 样的验证密码
# sentine1 auth-pass <master-name> <password>
sentine1 auth-pass mymaster MySUPER--secret-0123passwOrd
#指定多少毫秒之后主节点没有应答哨兵sentine1 此时哨兵主观上认为主节点下线默认30秒
# sentinel down-after-mi 11i seconds <master-name> <mi 11iseconds>
sentine1 down-after-mi 11iseconds mymaster 30000
#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成fai lover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而 不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentine1 paralle1-syncs <master-name> <numslaves>
sentine1 paralle1-syncs mymaster 1
#故障转移的超时时间failover-timeout 可以用在以下这些方面:
#1.同一个sentine1对同一 个master两次fai lover之间的间隔时间。
#2.当一个slave从一 个错误的master那里同步数据开始计算时间。直到s1ave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有s1aves指向新的master所需的最大时间。不过，即使过了这个超时，slaves 依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
#默认三分钟
# sentine1 failover-timeout <master-name> <milliseconds>
sentine1 fai lover-ti meout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被-一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentine1有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等)，将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等 方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一 个是事件的类型，一个是事件的描述。如果sentine1. conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentine1无法正常启动成功。
#通知脚本
# she11编程
# sentine1 notification-script <master-name> <script-path>
sentine1 notificati on-script mymaster /var/redis/notify. sh
#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state>总是“failover",
# <role>是“Teader"或者"observer"中的-一个。
#参数from-ip， from-port， to-ip，to-port是用来和旧的master和新的master(即旧的s lave)通信的
#这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentine1 client-reconfig-script <master-name> <script-path>
sentine1 client-reconfig-script mymaster /var/redis/reconfig.sh #一般都是由运维来配置!