共计 3605 个字符，预计需要花费 10 分钟才能阅读完成。
Redis 曾经大量利用于各种互联网架构场景中，其优异的性能，良好的操作性，以及大量的场景利用案例，使得 Redis 备受瞩目。本文作者向大家介绍了一种 Redis 在非大集群分布式应用场景下的灾备解决方案。一起来品读一下吧~一，Redis 简略介绍
Redis 是一个高性能的 key-value 非关系型数据库，因为其具备高性能的个性，反对高可用、长久化、多种数据结构、集群等，使其怀才不遇，成为罕用的非关系型数据库。
此外，Redis 的应用场景也比拟多。
- 会话缓存（Session Cache）
Redis 缓存会话有十分好的劣势，因为 Redis 提供长久化，在须要长时间放弃会话的利用场景中，如购物车场景这样的场景中能提供很好的长会话反对，能给用户提供很好的购物体验。 - 全页缓存
在 WordPress 中，Pantheon 提供了一个不错的插件wp-redis，这个插件能以最快的速度加载你已经浏览过的页面。 - 队列
Reids 提供 list 和 set 操作，这使得 Redis 能作为一个很好的音讯队列平台来应用。咱们常通过 Reids 的队列性能做购买限度。比方到节假日或者推广期间，进行一些流动，对用户购买行为进行限度，限度明天只能购买几次商品或者一段时间内只能购买一次。也比拟适宜实用。
- 排名
Redis 在内存中对数字进行递增或递加的操作实现得十分好。所以咱们在很多排名的场景中会利用 Redis 来进行，比方小说网站对小说进行排名，依据排名，将排名靠前的小说举荐给用户。 - 公布 / 订阅
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 主从复制长处与有余
- 长处
- 实现了对 master 数据的备份，一旦 master 呈现故障，slave 节点能够晋升为新的 master，顶替旧的 master 持续提供服务
- 实现读扩大。应用主从复制架构，个别都是为了实现读扩大。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…
