Redis主从复制 + Redis哨兵

Redis复制

主从复制实际上就是以master为主，slave为辅；当master的数据发生变化时，将会异步地同步数据到slave上；

• 使得读写分离，比如读找salve，写找master；
• 如果master出故障，也可以将slave当作master使用；实现数据备份
• 水平扩容，支持高并发

配置方法

配置从库而不配置主库；Redis默认情况下都是主库，需要在Redis中配置使得从库变成主库的附庸；

• master需要配置requirepass，使用密码登录
• slave要配置masterauth来设置主库的校验密码，否则master拒绝slave的访问请求

操作命令

• info replication 可以查看复制节点的主从关系和配置信息
• 在从机配置文件中设置 replicaof 主库ip和主库端口
• slaveof 主库ip和主库端口
  • 每次和master断开后，需要重新连接，直接设置配置文件则不需要
  • 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止与当前主数据库的同步，转而同步新的数据库
• slaveof no one 使当前数据库停止作为从库，转而变成主库

注意事项

• 先启动master，再启动slave
• 可以配置Redis的日志，其中存在是否同步成功的记录

主从复制

使用配置文件配置后

• 推荐先进行订阅，再进行发布，否则收不到消息
• 订阅的客户端每次可以收到一个3个参数的消息，包括消息的种类、始发频道的名称、实际的消息内容

从机是否可以写入

不可以，如果配置了master则从机拒绝一切写操作

slave是全局复制还是从切入点开始复制

是全部复制的，只要启动了从机就复制主机的全部数据

主机shutdown之后，会发生什么

主机出现问题后，从机不会变成主机，从机中的数据仍然可以访问，等待主机再次上线；主机再次上线后，从机继续复制主机的数据；

使用命令设置主从关系后

如果使用命令，从机重启后会发生什么

再次重启后，从机自动变为自己的主机，不再是命令配置的主机的从机

薪火相传

指的是，一个slave也可以作为其他slave的master，使得Redis之间的连接形成链条传递，这样可以减少主master的压力；

如果中途变更了与主库之间的关系，从库会清除之前的数据，重新拷贝新主库的数据;从库之间是不传递的，每个主库只能看到直接连接自己的slave

如果一个库既是主库又是从库，仍然不支持写操作

反客为主

通过设置slave of no one，可以解除自己的slave关系，使得自己变成了主库

复制原理和工作流程

主从复制启动流程

• slave配置主库，启动并连接主机，进行全量拷贝
  • 首次连接成功时，slave向master发送一个sync命令
  • 连接成功后，会执行一次全量复制，如果有其他的数据则清除并覆盖
• 首次连接，全量复制
  • master收到sync命令后，会开始在后台保存RDB（主从复制会触发RDB），同时将所有接收到用于修改的命令缓存，master完成持久化后，将rdb快照文件和所有的缓存命令发送到slave，以完成一次完全同步
  • slave接受到rdb文件后，将其加载并执行增量命令，完成初始化复制
• 心跳持续，保持通信
  • 配置文件中 repl-ping-replica-period 10 是配置了每10秒向slave发送一个心跳检测slave是否都在线
• 进入平稳，增量复制
  • master继续将收集到的修改命令发送给slave，完成同步
• 从机下线，重连续传
  • master检测backlog中的offset；master个slave都会保存一个offset和masterId，保存在backlog中；master发现从机上线后，可以把offset 之后的增量命令传给slave即可

主从复制的缺点

• 复制延时，因为master到slave有网络延时，slave越多导致延时越高c
• 过于依赖master，默认情况下不会在其余的库中选出一个master，导致系统崩溃，需要人工干预，无法实现无人值守

Redis哨兵

为了解决Redis复制时，主机宕机后导致系统无法写入的问题；吹哨人巡查监控后台master主机是否故障，如果故障则根据投票数自动将某一个从库转换为新主库，继续执行服务。

**哨兵：**监控Redis运行状态，包括master和slave；当master宕机后，自动将slave切换成master，实现无人值守

• 主从监控：监控主从Redis库是否正常运行
• 消息通知：将故障转移结果发送给客户端
• 故障转移：如果Master故障，进行主从切换，选择其中一个slave作为新master
• 配置中心：客户端可以通过连接哨兵获取当前Redis服务的主节点地址

哨兵案例

设置一些Redis服务器作为哨兵，不存放数据，只进行自动监控和维护集群；

设置一些主从机器来作为真实的服务器提供数据服务；一般需要给哨兵设置集群（防止哨兵出故障），并且设置为奇数（方便投票）

哨兵的配置文件和Redis的配置文件完全不一样，必须单独配置；

哨兵配置

其中有一些配置和普通的Redis一样，如注销bind、设置darmonize、设置protected-mode、设置端口、logfile、pidfile个dir；

• sentinel-monitor
  • 设置需要监控的Redis服务器
  • quorum表示最少有几个哨兵认可的客观下线，同意进行迁移的法定票数；表示如果有一定票数的哨兵认为主机下线了，就进行故障转移；这种检测是提供心跳检测的，这种方式是客观下线。
    • 这种方式是用来避免哨兵因为网络原因暂时无法于master进行沟通，造成误以为master的下线
• sentinel auth-pass
  • 设置监控master的密码
• sentinel down-after-milliseconds
  • 指定多少毫秒后，主节点没有应答，此时哨兵主观认为主节点下线
• sentinel parallel-syncs
  • 表示允许并行的slave个数，当master下线后，哨兵会选出新的master，此时剩余的slave会向新的master发起同步数据
• sentinel failover-timeout
  • 故障转移的超时时间，进行故障转移时默认构超过设置的毫秒，则表示转移失败
• sentinel notification-script
  • 当某一时间发生时，执行的脚本
• sentinel client-reconfig-script
  • 客户端重新配置主节点参数脚本

哨兵的默认端口是26379，如果从节点存在密码，需要在哨兵配置文件中配置sentinel auth-pass 使得哨兵可以从这些节点中选取新的主节点；如果出现问题，可以在设置的log目录中查看问题。

在启动主从机器和哨兵后，哨兵的配置文件会发生一些变化，包括自己的哨兵编号等信息；

哨兵选举

当主机下线，哨兵间将会进行通信，首先发现主观下线，之后触发客观下线；此时开始进行投票选取新的master，这些投票在哨兵集群中进行；选取成功后，选择一个哨兵对从机进行配置，使其变为主机；

当主机被关闭，需要等待一段时间，等待哨兵投票和改写配置，使得一个从机成为主机；新主机和其他从机的配置文件都会被改写，写成配置新主机的主从复制配置；

如果之前的主机再次上线，则会成为从机；因为哨兵会将重连的原主机配置成新的从机，到新的主机即可；

Broken Pipe：这一般是由于客户端关闭了进程导致的，对服务端没有影响；这是指在TCP连接管道中，远端已经发送了FIN信号通知管道关闭，如果继续向其中发送数据就会收到一个远端发送的RST信息，如果继续写数据就会收到操作系统的SIGPIPE信号并设置error为Broken pipe；

如果主机回到网络连接中，出现了master_link_status:down的问题，是因为主机变成从机时可能需要新主机的访问密码；所以，建议主从配置时使用统一的密码，并且在主从机器中都配置masterauth密码；

其他问题

如果哨兵宕机怎么办

如果少数的哨兵宕机不影响其他哨兵进行故障转移，并且哨兵必须部署中不同机器上，而且哨兵不进行高并发等性能要求高的工作，不易宕机；

而且一个哨兵可以监控多个master

哨兵运行流程和选举原理

• 一般是三个哨兵，一主二从的服务器配置
• 如果主机宕机了
  • 哨兵发现主机主观下线了（在一定时间内发送心跳没有收到主机回复），这个可以在配置文件中的down-after-milliseconds设置判断主观下线的时间长度（默认30秒），此时哨兵认为主机进入Sdown状态
  • 一个哨兵发现主机主观下线后，就会和其他哨兵通信，如果发现有一定数量的哨兵都主观认为主机下线了（达到quorum设置的值），就一致认为主机已经客观下线了
  • 哨兵达成主机客观下线的共识后，哨兵中协商选出一个leader来选择新的master，并且完成故障迁移的操作
    • 选举算法Raft：当主机客观下线后，每个哨兵都可以发出信息参与leader的竞选，并且将这个信息发送给其他哨兵；其他哨兵接收到这个信息，如果还没有发送过同意其他哨兵成为leader的信息，就会选举发送消息的哨兵成为leader，即只同意第一个参选信息的发送者；最早同步选举票数，选出票数最多的哨兵成为leader；如果故障迁移过程中leader也断线了，则会再次启动选举流程
  • leader选取成功后，由leader开始选取master
    • 在slave节点健康的情况下，选取策略为：先根据priority选择高的；如果优先级相同根据replication_offset选择较大的；如果复制偏移量也相同，则根据Run_id选出最小的；
    • priority是在配置文件中设置的，越小的优先级越高，默认是100
    • replication_offset是根据主从复制得到的，标记了目前复制的数据的相对多少，越大则表示和主库越接近
    • run_id是字典序表示的
  • leader选出新master后
    • leader会让被选出的节点先执行一个slaveof no one变成master节点
    • leader通过slaveof命令让其他节点成为新主节点的slave
• 原理的主机宕机，系统故障转移完成后
  • leader会检测宕机节点，如果再次上线，使其变成新主节点的slave

所有的操作都由哨兵完成，只要配置正确，可以实现无人值守

哨兵使用建议

• 哨兵数量应该是奇数，方便进行投票
• 哨兵应该配置多个，保证高可用
• 哨兵节点的配置应该是一致的，硬件也最好相似（否则可能导致较差配置的哨兵负担较大，导致转移较慢）
• 如果哨兵节点部署在Docker等桌面容器，要注意端口在正确映射
• 哨兵集群+主从复制不能保证数据零丢失（因为故障转移需要一定时间）