redis在生产中如何保证集群的高可用?

高可用指的是尽量减少服务的停工时间,保证redis的高可用,就是redis就算某个节点出现宕机,也不会影响到整个服务。这就需要redis节点之间的数据同步,需要用到redis主从复制机制,而这个机制的数据交互靠的是redis持久化机制。用来管理监控多个redis服务器需要用到哨兵机制,但是主从复制机制+哨兵机制还不足以保证redis的高可用,为什么呢?想想若是某个节点宕机了,不能自动重启会怎样?所以更稳妥的做法是再加上keepalived(自动重启)的支持,keepalived是集群中用来保证高可用的一个服务软件,防止单点故障。配置为若多次重启未成功,采用发邮件或短信的方式通知运维人员。

redis主从复制

主从复制机制分为两个角色,主master和从slave,redis支持一主多从,不支持多主多从。依靠主从复制机制实现数据库的读写分离,master数据库可以读写,slave数据库只能读。

主从复制分为全量同步和增量同步。

全量同步:

  1. 当一个slave数据库启动时,会像master发送sync命令
  2. master收到sync指令,主进程fork出一个子进程来创建rdb快照,并将期间的写命令记录到缓存区
  3. master完成保存快照后,会将快照文件发送给slave节点
  4. slave收到快照文件,会丢弃旧数据,载入收到的快照
  5. master发送快照后,会继续将缓存区的写记录发送给slave
  6. slave载入快照后,继续执行这写来自master缓存区的写命令

增量同步:slave数据库完成初始化后开始正常工作时,master数据库完成一个写操作都会同步给slave数据库

主从服务器刚连接时会进行全量同步,再进行增量同步。后续有需要,slave如何时候都可以发起全量同步。redis的策略是,优先增量同步,增量同步不成功,才会进行全量同步

哨兵机制

原理:总结两个点,心跳机制+投票裁决,心跳机制判断是否节点是否挂了,投票裁决选举master节点

心跳机制:redis sentinel(哨兵)向master和slave定时发送消息(ping),后者在收到后需要在规定的时间内回应(pong)。若未在指定的时间内回应,就主观认为对方已挂,即Subjective Down,简称sdown

投票裁决:若哨兵群中多数sentinel,都报告某个master节点没响应,就认为这个master节点彻底挂了,这是客观上的真正down机,即Objective Down,简称odown。再通过vote算法,从剩下的slave节点中选举出一台提升为master,然后自动修改相关的配置

redis宕机如何解决?

按照上面介绍的主从复制机制和哨兵机制,这个问题就很好回答了。

如果是单机redis,那么数据肯定会有丢失,生产中也不会有单机的情况。

针对主从架构,从两个方面考虑这个问题:

slave宕机

从redis从库中重新启动,会自动加入主从架构中,完成数据同步,如果做了持久化,就会完成增量同步

master宕机

使用哨兵机制选举出一台新的master,此时再重启原来的master,并执行SLAVEOF,变成slave,加入主从自动完成数据同步