首先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。避免了对业务的影响,提高运维效率。部署哨兵时,建议使用奇数个哨兵节点,至少三个哨兵节点。
