共计 1315 个字符，预计需要花费 4 分钟才能阅读完成。
redis在生产中如何保证集群的高可用？
高可用指的是尽量减少服务的停工时间，保证redis的高可用，就是redis就算某个节点出现宕机，也不会影响到整个服务。这就需要redis节点之间的数据同步，需要用到redis主从复制机制，而这个机制的数据交互靠的是redis持久化机制。用来管理监控多个redis服务器需要用到哨兵机制，但是主从复制机制+哨兵机制还不足以保证redis的高可用，为什么呢？想想若是某个节点宕机了，不能自动重启会怎样？所以更稳妥的做法是再加上keepalived（自动重启）的支持，keepalived是集群中用来保证高可用的一个服务软件，防止单点故障。配置为若多次重启未成功，采用发邮件或短信的方式通知运维人员。
redis主从复制
主从复制机制分为两个角色，主master和从slave，redis支持一主多从，不支持多主多从。依靠主从复制机制实现数据库的读写分离，master数据库可以读写，slave数据库只能读。
主从复制分为全量同步和增量同步。
全量同步：
- 当一个slave数据库启动时，会像master发送sync命令
- master收到sync指令，主进程fork出一个子进程来创建rdb快照，并将期间的写命令记录到缓存区
- master完成保存快照后，会将快照文件发送给slave节点
- slave收到快照文件，会丢弃旧数据，载入收到的快照
- master发送快照后，会继续将缓存区的写记录发送给slave
- 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，加入主从自动完成数据同步
