redis高可用（redis高可用集群）

本篇文章给大家谈谈redis高可用，以及redis高可用集群对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis哨兵(Sentinel)机制 --高可用的保障
• 2、redis高可用是什么
• 3、Kubernetes Redis 高可用方案
• 4、redis高可用cp还是ap
• 5、Redis高可用（哨兵机制）
• 6、调研Redis高可用两种方案

Redis哨兵(Sentinel)机制 --高可用的保障

哨兵机制是用来解决主从同步Master宕机后的 动态自动主从切换 问题。

主要有以下作用

试想如果用来保障redis集群高可用的哨兵是单机的，然后哨兵挂了，redis也挂了，这tm是何等 卧槽？ 所以哨兵也是集群的，所有操作需要进行投票决定。

（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

（2）即使部分哨兵节点挂掉了，哨兵集群还是能瞎扰正常工作的。

（1）哨兵 至少需信宴要3个实例 ，来保证自己的 健壮性

（2）哨兵 + redis主从的部署架构，是 不会保证数据零丢失 的， 只能保证redis集群的高可用性

我们在多个机器部署哨兵，它们需要共同协作完成一项任务，所以它们就组成了一个「分布式系统」。

在分布式系统领域，多个节点如何就一个问题达成共识的算法，就叫共识算法。

在这个场景下，多个哨兵共同协商，选举出一个都认可的领导者，就是使用共识算法完成的。

这个算法还规定节点的数量必须是奇数个，这样可以保证系统中即使有节点发生了故障，剩余超过「半数」的节点状态正常，依旧可以提供正确的结果，也就是说，这个算滑神银法还兼容了存在故障节点的情况。

共识算法在分布式系统领域有很多，例如 Paxos、Raft，哨兵选举领导者这个场景，使用的是 Raft 共识算法 ，因为它足够简单，且易于实现。

sdown和odown两种失败状态

sdown达成的条件很简单，如果一个哨兵 ping 一个master，超过了 is-master-down-after-milliseconds （哨兵配置文件里可配置）指定的毫秒数之后，就主观认为master宕机

sdown到odown转换 的条件很简单，如果一个哨兵在 指定时间 内，收到了 quorum指定数量 的 其他哨兵也认为那个master是sdown了 ，那么就认为是odown了，客观认为master宕机。

哨兵互相之间的发现，是通过 redis的pub/sub系统 实现的，每个哨兵都会往 __sentinel__:hello 这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每隔两秒钟 ，每个 哨兵 都会往自己监控的某个 master+slaves 对应的 __sentinel__:hello channel里 发送 一个消息，内容是自己的 host、ip和runid 还有对这个master的 监控配置

每个哨兵也会去 监听 自己监控的每个master+slaves对应的 __sentinel__:hello channel，然后去 感知 到同样在监听这个master+slaves的 其他哨兵 的存在

每个哨兵还会跟其他哨兵 交换 对master的 监控配置 ，互相 进行监控配置的同步

哨兵会负责自动纠正 slave的一些配置 ，比如如果master宕机了，选举出了新的master，原来slave连接到了一个错误的master上，故障转移之后，那么哨兵会确保它们连接到正确的master上

如果一个master被认为odown了，而且majority哨兵（大多数哨兵数量）都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

选举新的主节点会 考虑slave的一些信息

（1）跟master断开连接的时长过长的被先过滤掉，然后进行选择

（2）slave优先级

（3）复制offset

（4）run id

首先：如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么 该slave就被认为不适合选举为master -- (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

除去断开连接过长的结点，接下来会对slave进行排序

（1）按照 slave优先级 进行排序， slave priority越低，优先级就越高

（2）如果slave priority相同，那么看 replica offset ， 哪个slave复制了越多的数据，offset越靠后，优先级就越高

（3）如果上面两个条件都相同，那么选择一个 run id比较小 的那个slave

主要有一个根本原则就是推断那个slave拥有的数据是最新的；

quorum：达到odwn的条件。

majority：主备切换的条件。

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

哨兵会对一套redis master+slave进行监控，有相应的监控的配置， configuration epoch 就是一个 version号 ，每次切换的version号都必须是 唯一 的。（configuration epoch 用于从结点比较自己的配置是否是最新的，可看第8点）

执行切换的那个哨兵，会从要切换到的新master（salve-master）那里得到一个configuration epoch,拿到了之后该哨兵就去切换主从结点。

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后 接替 继续执行切换 ，此时会 重新获取 一个 新的configuration epoch，作为新的version号

哨兵完成切换之后，会在自己本地更新生成最新的 master配置 ，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的。

其他的哨兵都是根据版本号的大小来更新自己的master配置的，（ 如果发现自己的version落后于拿到的version就会更新自己的master配置 ）

redis高可用是什么

1、什么是99.99%高可用？

架构上，高可用性，99.99%的高可用性

讲的学术，99.99%，公式，系统可用的时间胡大 / 系统故障的时间，365天，在365天 * 99.99%的时间内，你的系统都是可以哗哗对外提供服务的，那就是高可用性，99.99%

系统可用的时间 / 总的时间 = 高可用性，然旦做孙后会对各种时间的概念，说一大堆解释

2、redis不可用是什模链么？单实例不可用？主从架构不可用？不可用的后果是什么？

3、redis怎么才能做到高可用？

Kubernetes Redis 高可用方案

Redis 高可用方仿友案常用的有两种：Redis Sentinel 和 Redis Cluster ，本篇笔记介绍这两种方案如何在 Kubernetes 中部署。在 Kubernetes 里部署服务通常有三种方式：自己手写 Kubernetes 资源描述文件（Manifests YAML）、Helm Chart 和 Operator 。手写资源描述文件需要对配置非常熟悉才能写的好，对于初学者吵则一般采用 Helm 或者 Operator 方式安装，这里采用 Operator ，之所以选择 Operator ，是因为本着最简安装的原则，使用 Operator 方式安装可以少安装一个组备碰槐件 Helm 。

安装 Operator 以及相关权限：

注意： -c 这个参数是需要加上的，否则会报错，因为按照分配算法需要 redis-cli 能够对 Cluster 自动寻址。

[img]

redis高可用cp还是ap

高可用选择ap。

高可用选择AP但大多数网站架构的选好友择 CP Redis、Mongodb 注意：分布式架构拦敬的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要简袜慎强一致性。

Redis高可用（哨兵机制）

master和slave的主从切换，保证了服务的高可用；

sential本身也需要部署，并且也是集群的方式部署，然后和redis集群一起协同工作。

哨兵至少部署三或旦扒个实例，

因为哨兵采用的是多数选举机制，比如3个节点，多数是2；5个节点，多数是3.。。。

当多数哨兵都认为master挂了，可以进行故障转迟段移，才能进行转移。

如果只部署了2个节点，而2个节点的多数还是2。假设一个哨兵节点挂了，那么剩下的一个是无法进行故障转移判断的。

所以经典的哨兵部署是3个节点，gurom=2；（节点数和gurom比较，取衫昌大者）

调研Redis高可用两种方案

导读：Redis是被广泛使用的基础软件之一。对于工程师和,架构师，运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。

作者 codedump codedump.info 博主，多年从事陆让互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。

Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：

Redis中主从节点复制数据有全量复制和部分复制之分。

全量复制使用snyc命令来实现，其流程是：

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。

新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。

执行复制的双方，主从服务器，分别会维护一个复制偏移量：

主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。

在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。

每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。

从服务器Redis断线重连之后进行同液丛步时，就是根据运行ID来判断同步的进度：

有了前面的准备，下面开始分析psync命令的流程：

前面两种情况主服务器收到psync命令之后，会出现以下三种可能：

Redis使用哨兵机制来实现高可用(HA)，其大概工作原理闹悉樱是：

以上将Redis节点分为两类：

以上是大体的流程，这个流程需要解决以下几个问题：

以下来逐个回答这些问题。

哨兵节点通过三个定时监控任务监控Redis数据节点的服务可用性。

每隔10秒，每个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。

Redis拓扑结构信息包括了：

这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。

这一操作实际上完成了两件事情： * 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 * 交换主节点的状态信息，作为后续客观判断主节点下线的依据。

每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。

当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。

这个选举的大体思路是：

可以看到，这个选举领导者的流程很像raft中选举leader的流程。

在剩下的Redis从节点中，按照以下顺序来选择新的主节点：

选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：

原文地址：

参考阅读：

GIAC全球互联网架构大会深圳站将于2019年6月举行，掌阅资深架构师，畅销图书《Redis 深度历险：核心原理与应用实践》作者钱文品将作为数据库专场的讲师出席2019年GIAC深圳站，并做关于Redis高性能，高可用方面的的演讲。本届GIAC数据库专场邀请阿里云前数据库总负责人余峰作为出品人，议题如下。

参加 GIAC，盘点2019年最新技术，目前 购买7.5折优惠 ，多人购买有更多优惠。识别二维码 了解大会更多详情。

关于redis高可用和redis高可用集群的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。