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