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

标签: 运维干货 Redis Redis 备份 容灾 高可用 | 发表时间:2017-09-12 09:26 | 作者:小码哥
出处:http://www.yunweipai.com

作者介绍

郝朝阳,宜搜科技,运维工程师,负责前端运维工作。专注于运维自动化的实现。致力于DevOps思想的推广,帮助企业形成形成自有文化的运维体系建设。

一、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主从复制

  • 方案一

Redis这是最常见的一种架构,一个Master节点,两个Slave节点。客户端写数据的时候是写Master节点,读的时候,是读取两个Slave,这样实现读的扩展,减轻了Master节点读负载。

  • 方案二

Maste

  • 这种架构同样是一个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

七、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知识点比较多,这里仅给大家进行介绍,让大家有个了解,想了解更多可与我联系。谢谢。

相关 [redis 备份] 推荐:

[原]Redis 数据备份与恢复

- - 芝麻软件工作室的专栏
Redis SAVE 命令用于创建当前数据库的备份. redis Save 命令基本语法如下:. 该命令将在 redis 安装目录中创建dump.rdb文件. 如果需要恢复数据,只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可. 获取 redis 目录可以使用 CONFIG 命令,如下所示:.

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

- - 运维派
郝朝阳,宜搜科技,运维工程师,负责前端运维工作. 致力于DevOps思想的推广,帮助企业形成形成自有文化的运维体系建设. Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库. 此外,Redis的使用场景也比较多.

Redis数据备份方案-Luffy的梦-51CTO博客

- -
###只是为了查询方便,方法为借鉴网络的文章,文章贴在这里供参考: http://blog.csdn.net/subuser/article/details/8157178. Redis提供了两种持久化选项,分别是RDB和AOF. 默认情况下60秒刷新到disk一次[save 60 10000 当有1w条keys数据被改变时],Redis的数据集保存在叫dump.rdb一个二进制文件,这种策略被称为快照.

Redis 负载监控——redis-monitor

- - ITeye资讯频道
redis-monitor是一个Web可视化的 redis 监控程序. 使用 Flask 来开发的,代码结构非常简单,适合移植到公司内网使用. redis 服务器信息,包括 redis 版本、上线时间、 os 系统信息等等. 实时的消息处理信息,例如处理 command 数量、连接总数量等. 内存占用、 cpu 消耗实时动态图表.

Redis 起步

- - 博客园_首页
Rdis和JQuery一样是纯粹为应用而产生的,这里记录的是在CentOS 5.7上学习入门文章:. Redis是一个key-value存储系统. 和Memcached类似,但是解决了断电后数据完全丢失的情况,而且她支持更多无化的value类型,除了和string外,还支持lists(链表)、sets(集合)和zsets(有序集合)几种数据类型.

redis 配置

- - 谁主沉浮
# 当配置中需要配置内存大小时,可以使用 1k, 5GB, 4M 等类似的格式,其转换方式如下(不区分大小写). # 内存配置大小写是一样的.比如 1gb 1Gb 1GB 1gB. # daemonize no 默认情况下,redis不是在后台运行的,如果需要在后台运行,把该项的值更改为yes. # 当redis在后台运行的时候,Redis默认会把pid文件放在/var/run/redis.pid,你可以配置到其他地址.

Cassandra代替Redis?

- - Tim[后端技术]
最近用Cassandra的又逐渐多了,除了之前的360案例,在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例. 而这篇 百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例. 考虑到到目前仍然有不少网友在讨论Redis的用法问题,Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题,因此简单谈下相关区别.

redis 部署

- - CSDN博客云计算推荐文章
一、单机部署 tar xvf redis-2.6.16.tar.gz cd redis-2.6.16 make make PREFIX=/usr/local/redis install  #指定安装目录为/usr/local/redis,默认安装安装到/usr/local/bin. # chkconfig: 2345 80 10       #添加redhat系列操作系统平台,开机启动需求项(运行级别,开机时服务启动顺序、关机时服务关闭顺序) # description:  Starts, stops redis server.

nagios 监控redis

- - C1G军火库
下载check_redis.pl. OK: REDIS 2.6.12 on 192.168.0.130:6379 has 1 databases (db0) with 49801 keys, up 3 days 14 hours - connected_clients is 1, blocked_clients is 0 | connected_clients=1 blocked_clients=0.

转 redis vs memcached

- - 数据库 - ITeye博客
传统MySQL+ Memcached架构遇到的问题.   实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:.   1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间.