一.Redis简单介绍Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。此外,Redis的使用场景也比较多。
此外还有很多其它场景,Redis都表现的不错。 二.Redis使用中单点故障问题正是由于Redis具备多种优良特新,且应用场景非常丰富,以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富,但部分公司在实践Redis应用的时候还是相对保守使用单节点部署,那为日后的维护带来了安全风险。 在2015年的时候,曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署,采用单实例部署,并未考虑容灾方面的问题。 当时我们通过Redis服务器做用户购买优惠商品的行为控制,但后来由于未知原因Redis节点的服务器宕机了,导致我们无法对用户购买行为进行控制,造成了用户能够在一段时间内多次购买优惠商品的行为。 这种宕机事故可以说已经对公司造成了不可挽回的损失了,安全风险问题非常严重,作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。 三.非分布式场景下Redis应用的备份与容灾Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。 常用Redis主从复制方案一 这是最常见的一种架构,一个Master节点,两个Slave节点。客户端写数据的时候是写Master节点,读的时候,是读取两个Slave,这样实现读的扩展,减轻了Master节点读负载。 方案二 这种架构同样是一个Master和两个Slave。不同的是Master和Slave1使用keepalived进行VIP转移。Client连接Master的时候是通过VIP进行连接的。避免了方案一IP更改的情况。 Redis主从复制优点与不足
架构方案一 当Master出现故障时,Client就与Master端断开连接,无法实现写功能,同时Slave也无法从Master进行复制。 此时需要经过如下操作(假设提升Slave1为Master):
架构方案二 当master出现故障后,Client可以连接到Slave1上进行数据操作,但是Slave1就成了一个单点,就出现了经常要避免的单点故障(single point of failure)。 之后需要经过如下操作:
可以发现,无论是哪种架构方案都需要人工干预来进行故障转移(failover)。需要人工干预就增加了运维工作量,同时也对业务造成了巨大影响。这时候可以使用Redis的高可用方案-Sentinel 四.Redis Sentinel介绍Redis Sentinel为Redis提供了高可用方案。从实践方面来说,使用Redis Sentinel可以创建一个无需人为干预就可以预防某些故障的Redis环境。Redis Sentinel设计为分布式的架构,运行多个Sentinel进程来共同合作的。运行多个Sentinel进程合作,当多个Sentinel同一给定的master无法再继续提供服务,就会执行故障检测,这会降低误报的可能性。 五.Redis Sentinel功能Redis Sentinel在Redis高可用方案中主要作用有如下功能:
六.Redis Sentinel架构七.Redis Sentinel实现原理Sentinel集群对自身和Redis主从复制进行监控。当发现Master节点出现故障时,会经过如下步骤: 1)Sentinel之间进行选举,选举出一个leader,由选举出的leader进行failover 2)Sentinel leader选取slave节点中的一个slave作为新的Master节点。对slave选举需要对slave进行选举的方法如下:
3) Sentinel leader会在上一步选举的新master上执行slaveof no one操作,将其提升为master节点 4)Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave 5)Sentinel leader会让原来的master降级为slave,当恢复正常工作,Sentinel leader会发送命令让其从新的master进行复制以上failover操作均有sentinel自己独自完成,完全无需人工干预。 总结使用sentinel实现了Redis的高可用,当master出现故障时,完全无需人工干预即可实现故障转移。避免了对业务的影响,提高了运维工作效率。在部署sentinel的时候,建议使用奇数个sentinel节点,最少三个sentinel节点。 |
|