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...