首先Redis简单介绍一下Redis是一个高性能的key-value非关系型数据库。由于其高性能特性，支持高可用、持久化、多种数据结构、集群等，使其作为常用的非关系型数据库脱颖而出。此外，Redis还有很多使用场景。1.会话缓存（SessionCache）Redis缓存会话有一个很好的优势，因为Redis提供了持久化，在需要长时间保持会话的应用场景，比如购物车场景，可以提供很好的长会话支持，可以为用户提供良好的购物体验。2.全页缓存在WordPress中，Pantheon提供了一个很好的插件wp-redis，可以以最快的速度加载你浏览过的页面。3.QueueReids提供list和set操作，这使得Redis成为一个很好用的消息队列平台。我们经常使用Reids的排队功能来限购。比如在节假日或者促销期间，进行一些限制用户购买行为的活动，限制当天可以购买的数量或者一段时间内只能购买一次。也更适合应用。4.排名Redis可以很好地增加或减少内存中的数字。因此，我们会在很多排名场景中使用Redis。例如，某小说网站对小说进行排名，根据排名向用户推荐排名靠前的小说。5.发布/订阅Redis提供了发布和订阅功能。发布和订阅的场景有很多种。例如，我们可以实现一个基于脚本触发器的发布和订阅，利用Redis的发布和订阅功能构建的聊天系统。除此之外，还有很多其他的场景，Redis表现不错。其次，Redis在使用中出现单点故障的问题正是因为Redis具有多种优秀的特性，而且应用场景非常丰富，以至于Redis在各个公司都有它的身影。那么问题和风险也随之而来。尽管Redis拥有丰富的应用场景，但部分企业在实践Redis应用时，仍然相对保守地采用单节点部署，这给以后的维护带来了安全隐患。2015年，我们处理了一个单点故障导致的业务中断问题。当时Redis并没有采用分布式部署，而是单实例部署，没有考虑容灾问题。当时我们使用Redis服务器来控制用户购买打折商品的行为。但由于不明原因，Redis节点服务器宕机，我们无法控制用户的购买行为，导致用户在一段时间内多次购买打折商品。的行为。这种停机事故可以说给公司造成了无法弥补的损失，安全隐患非常严重。作为当时系统的运维人员，我有必要修复这个问题，改进结构。于是开始研究研究解决非分布式应用下的Redis单点故障问题。三、Redis应用在非分布式场景下的备份和容灾Redis主从复制现在应该已经很普遍了。常用的主从复制架构有以下两种架构方案。常用的Redis主从复制方案1这是最常见的架构，有一个Master节点和两个Slave节点。client写数据的时候写到Master节点，读的时候读两个Slave，实现了读的扩展，降低了Master节点的读负载。方案2这种架构也是一个Master和两个Slave。不同的是Master和Slave1使用keepalived进行VIP传输。当Client连接到Master时，它通过VIP连接。这样就避免了方案一换IP的情况。Redis主从复制的优缺点优势实现主数据的备份。一旦master发生故障，slave节点可以提升为新的master，取代旧的master继续提供服务，实现读扩展。使用主从复制架构一般是为了实现读扩展。Master主要实现写功能，Slave实现读功能。架构方案不足：当Master出现故障时，Client会与Master断开连接，无法实现写入功能。同时，Slave不能从Master复制。此时需要进行如下操作（假设Slave1提升为Master）：1）在Slave1上执行slaveofnoone命令，将Slave1提升为新的Master节点。2）在Slave1上配置为可写，因为大多数情况下slave的配置是只读的。3）告诉客户端（也就是连接Redis的程序）新Master节点的连接地址。4）配置Slave2从新的Master复制数据。架构方案2当master出现故障时，Client可以连接到Slave1进行数据操作，但是Slave1变成了单点，经常需要避免的单点故障（singlepointoffailure）就出现了。之后还需要经过以下操作：1）在Slave1上执行slaveofnoone命令，将Slave1升级为新的Master节点2）在Slave1上配置为可写，因为大多数情况下，Slave的配置是读-只有3)ConfigureSlave2从新的Master复制数据时，可以发现无论是哪种架构方案，都需要人工干预进行failover。需要人工干预，增加了运维的工作量，对业务也产生了巨大的影响。这时候就可以使用Redis的高可用解决方案——Sentinel4，RedisSentinel介绍RedisSentinel为Redis提供了高可用解决方案。从实用的角度来看，使用RedisSentinel可以创建一个Redis环境，可以在没有人为干预的情况下防止某些故障。RedisSentinel被设计为分布式架构，运行多个Sentinel进程协同工作。运行多个Sentinel进程进行协作，当给定master的多个Sentinel不能再继续提供服务时，会进行故障检测，减少误报的可能性。五、RedisSentinel功能RedisSentinel在Redis高可用方案中有以下主要功能：监控Sentinel会不断检查主从是否正常运行Notification通过API，Sentinel可以通知系统管理员和Redis实例由程序监控发生自动故障转移。如果master没有按预期正常运行，Sentinel可以启动故障转移过程。其中一个slave将被提升为master，而其他slave将被重新配置以使用新的master。使用Redis服务的应用程序，在连接时，也会通知它使用新的地址。配置提供者Sentinel可以用作客户端服务发现的身份验证源：客户端连接到Sentinel以获取当前负责给定服务的Redismaster的地址。如果发生故障转移，Sentinel将报告新地址。六、RedisSentinel架构七、RedisSentinel实现原理Sentinel集群自我监控和Redis主从复制。当发现Master节点故障时，会进行以下步骤：1）Sentinels之间的选举，选出一个leader，选出的leader进行故障转移2）Sentinelleader选择其中一个slave节点作为新的Master节点。slave选举的方法如下：a)从master断开连接时间如果从master断开连接时间超过down-after-milliseconds（sentinel配置）*10秒再加上从sentinel判断master不可用到sentinel启动之间的时间执行从站被认为不适合提升为主站的故障转移。b)slave优先级每个slave都有一个优先级，保存在redis.conf配置文件中。如果优先级相同，则继续。c)复制偏移位置复制偏移记录从master复制的数据被复制到哪里。copyoffset越大，从master接受的数据越多。如果副本偏移量相同，则继续选举。d)RunID选举有RunID最小的Slave作为新的Master流程图如下：3)Sentinelleader会对上一步选出的新master执行slaveofnoone操作，并提升为master节点4)Sentinelleader向其他slave发送命令，让剩下的slave成为新master节点的slave5)Sentinelleader会将原来的master降级为slave。当它恢复正常工作时，Sentinelleader会发送命令让它从新的master复制。以上故障转移操作都是sentinel自己完成的，不需要人为干预。总结使用sentinel实现Redis的高可用，当master出现故障时，无需人工干预即可实现failover。避免了对业务的影响，提高运维效率。部署哨兵时，建议使用奇数个哨兵节点，至少三个哨兵节点。
