Redis 备份、容灾及高可用实战

Redis已经大量应用于各类互联网架构场景中，其优异的性能，良好的操做性，以及大量的场景应用案例，使得Redis备受瞩目。本文做者向你们介绍了一种Redis在非大集群分布式应用场景下的灾备解决方案。一块儿来品读一下吧~

一，Redis简单介绍

Redis是一个高性能的key-value非关系型数据库，因为其具备高性能的特性，支持高可用、持久化、多种数据结构、集群等，使其脱颖而出，成为经常使用的非关系型数据库。
此外，Redis的使用场景也比较多。

1. 会话缓存（Session Cache）
   Redis缓存会话有很是好的优点，由于Redis提供持久化，在须要长时间保持会话的应用场景中，如购物车场景这样的场景中能提供很好的长会话支持，能给用户提供很好的购物体验。
2. 全页缓存
   在WordPress中，Pantheon提供了一个不错的插件wp-redis，这个插件能以最快的速度加载你曾经浏览过的页面。
3. 队列
   Reids提供list和set操做，这使得Redis能做为一个很好的消息队列平台来使用。

   咱们常经过Reids的队列功能作购买限制。好比到节假日或者推广期间，进行一些活动，对用户购买行为进行限制，限制今天只能购买几回商品或者一段时间内只能购买一次。也比较适合适用。

4. 排名
   Redis在内存中对数字进行递增或递减的操做实现得很是好。因此咱们在不少排名的场景中会应用Redis来进行，好比小说网站对小说进行排名，根据排名，将排名靠前的小说推荐给用户。
5. 发布/订阅
   Redis提供发布和订阅功能，发布和订阅的场景不少，好比咱们能够基于发布和订阅的脚本触发器，实现用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主从复制优势与不足

• 优势

1. 实现了对master数据的备份，一旦master出现故障，slave节点能够提高为新的master，顶替旧的master继续提供服务
2. 实现读扩展。使用主从复制架构， 通常都是为了实现读扩展。Master主要实现写功能，  Slave实现读的功能

• 不足
  架构方案一
  当Master出现故障时，Client就与Master端断开链接，没法实现写功能，同时Slave也没法从Master进行复制。
  

此时须要通过以下操做(假设提高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 Sentinel为Redis提供了高可用方案。从实践方面来讲，使用Redis Sentinel能够建立一个无需人为干预就能够预防某些故障的Redis环境。
Redis Sentinel设计为分布式的架构，运行多个Sentinel进程来共同合做的。运行多个Sentinel进程合做，当多个Sentinel同一给定的master没法再继续提供服务，就会执行故障检测，这会下降误报的可能性。

五，Redis Sentinel功能

Redis Sentinel在Redis高可用方案中主要做用有以下功能：

• 监控
  Sentinel会不断的检查master和slave是否像预期那样正常运行
• 通知
  经过API，Sentinel可以通知系统管理员、程序监控的Redis实例出现了故障
• 自动故障转移
  若是master不像预想中那样正常运行，Sentinel能够启动故障转移过程，其中的一个slave会提成为master，其它slave会从新配置来使用新的master，使用Redis服务的应用程序，当链接时，也会被通知使用新的地址。
• 配置提供者
  Sentinel能够作为客户端服务发现的认证源：客户端链接Sentinel来获取目前负责给定服务的Redis master地址。若是发生故障转移，Sentinel会报告新的地址。

六，Redis Sentinel架构

七，Redis Sentinel实现原理

Sentinel集群对自身和Redis主从复制进行监控。当发现Master节点出现故障时，会通过以下步骤：

• 1）Sentinel之间进行选举，选举出一个leader，由选举出的leader进行failover

• 2）Sentinel leader选取slave节点中的一个slave做为新的Master节点。对slave选举须要对slave进行选举的方法以下：

  a) 与master断开时间
   若是与master断开的时间超过down-after-milliseconds(sentinel配置） * 10秒加上从sentinel断定master不可用到sentinel开始执行故障转移之间的时间，就认为该slave不适合提高为master。
  b) slave优先级
  每一个slave都有优先级，保存在redis.conf配置文件里。若是优先级相同，则继续进行。
  c) 复制偏移位置
  复制偏移纪录着从master复制数据复制到哪里，复制偏移越大代表从master接受的数据越多，若是复制偏移量也同样，继续进行选举
  d) Run ID
  选举具备最小Run ID的Slave做为新的Master
  流程图以下：
  

• 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节点。

写在最后

因为sentinel知识点比较多，这里仅给你们进行介绍，让你们有个了解。

原文：https://www.sohu.com/a/167105...