redis3.0高可用，redis 高可靠

调研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折优惠 ，多人购买有更多优惠。识别二维码 了解大会更多详情。

相关问答

Q1: 如何利用Redis扩展数据服务，实现分片及高可用

应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql。同时要注意避免冲突，在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。这样处理，主要是实时读写redis，而mysql数据则通过队列异步处理，缓解mysql压力，不过这种方法应用场景主要基于高并发，而且redis的高可用集群架构相对更复杂，一般不是很推荐。

Q2: redis高可用实践之FAILOVER

服务的可用性不仅仅是指服务健康运行的时间，还包括出现故障以后的恢复速度。保证一个服务的高可用，基本可以从 软件质量 故障预防 故障恢复三方面着手。对于redis，软件的质量本身有很大的保障，因此对于线上大规模的redis集群运维管理，基本上可以从故障预防和故障恢复两方面着。虽然redis cluster本身具有自动主从容灾的高可用能力，但是某些场景cluster依然无法很好地处理。本文将结合CLUSTER FAILOVER 集群管理命令详细介绍如何进一步提升redis集群的可用性。

首先对CLUSTER FAILOVER命令做个介绍:

CLUSTER FAILOVER处理流程

该操作用于正常的主从切换，但是如果master节点宕机了无法响应failover请求，那么failover将会失败，为了处理master宕机的情况，可以添加FORCE 选项。

CLUSTER FAILOVER FORCE: 添加FORCE选项时，failover流程直接从上述的第4步开始，也即跳过了和旧master通信协商复制数据的过程，当master宕机时，force选项可以快速进行人工主从切换。但是该过程仍然需要获得半数master的统=同意才能当选为新主。当出现半数master节点异常时，该流程无法进行主从切换。

CLUSTER FAILOVER TAKEOVER: 为了处理半数master节点异常的场景，可以添加****TAKEOVER 选项。通过TAKEOVER 选项，可以无需获得半数master的认同，而是直接更新状态为master并向所有可达的节点发送最新配置epoch。****

接下来将结合场景介绍如何通过FAILOVER 提升集群可用性

防患以未然，当机器负载过高或者出现异常故障时，需要将部署在该机器的redis实例迁移出,迁移流程包含:

如果旧机器有实例处于master，则需要先将role改外slave，然后在进行迁移，此时可以通过对slave节点发送cluster failover，将节点改为slave以后在进行删除。

最理想的情况是出现故障之前提前解决处理，但是这毕竟只是理想。当节点宕机或者负载过高导致无法响应时，可能出现FAILOVER失败的情况，此时则可以通过添加FORCE选项进行强制主从切换，将健康的slave节点提升为master从而快速恢复服务。

虽然在线上环境的部署上，redis的master节点会做到尽可能分散，但是在某些场景写，还是可能出现半数master节点故障的情况:

虽然redis cluster本身提供了高可用的能力，但是在某些场景下依然需要人为介入进行处理，本文介绍了FAILOVER的几种应用实践场景，通过将该操作和option集成到自动运维平台，进一步提升了redis的可用性。

Q3: Paxos、Raft、ZAB、Gossip 分布式一致性算法理解

以下各种工程实现都是一个在CAP之间tradeoff的过程

采用zab算法，满足写强一致性（过半节点），读最终一致性（所有节点）

采用租约机制确保并发写入的顺序性和采用hflush机制实现文件的最小副本可见性，满足写强一致性（满足hfds最小副本数，其它副本hdfs自动异步同步），读最终一致性（所有副本），实现弱分区容错性

kafka 读写都在leader上，配合acks=all，实现了读写强一致性，ISR机制确保了高可用性，副本机制实现了分区容错性

hbase读写rowkey都在特定region上，实现读写强一致性，弱高可用性（region存在单点故障），分区容错性hdfs来实现

redis3.0实现Redis-Cluster，采用Gossip协议进行redis元数据广播，实现了元数据读写最终一致性，并且采用shard-master和shard-slave机制实现高可用性，分区容错性

在分布式系统中，需要提供维护节点元数据信息的机制，所谓元数据是指节点负责哪些数据、主从属性、是否出现故障等状态信息。常见的元数据维护方式分为集中式和无中心式。Redis Cluster 采用 Gossip 协议实现了无中心式。

实现原理同redis-cluster，实现了读写最终一致性，高可用和分区容错性

NameNode与JournalNode Cluster进行数据读写时核心点是需要大多数JN成功返回才可认为本次请求有效

在JournalNode Cluster中所有JN之间完全对等，不存在Primary/Secondary区别，实现原理类似paxos

QJM机制实现的是最终一致性

参考

Q4: redis集群怎么保证写操作在master上

如果把master和slave放在同一台机器上，会有问题：

master和slave运行时都需要占用内存，机器的内存可能不够用

如果机器宕机，断电，或者网络断开，那么master和slave没有什么高可用可言了。

master和slave最好都要放在不同的机器。

至于为什么是3而不是2。这是集群选举的时候的最佳策略。redis3.0开始支持集群。

一般，集群要对某个公共状态达成共识，都需要集群中过半数的redis实例同意。

为什么要过半数呢，因为要考虑集群发生脑裂(split-brain)的情况，也就是网络隔离(network-partition)，

过半数可以保证，无论网络怎么隔离，无论脑怎么裂，无论大集群被隔离成了多少个小集群，能够提供服务(意味着有过半数的实例)的那个小集群里，至少有一个实例是同步到最新的状态信息的。

在理解上面所说的过半数，然后才有背景来谈谈为什么是奇数的问题

偶数也可以有过半数，例如，4个实例的集群，3就是一个过半数。

但为什么还是奇数最好？

如果集群有5个实例，那么只能容忍2个实例的崩溃。

如果集群中有6个实例，同样也只能容忍2个实例的崩溃。

在相同的容忍度下，6个和5个有什么区别：

由于集群间需要互相通信，实例越多，网络开销越大

实例越多，5个实例的时候，发生3个实例崩溃的概率要小于6个实例的时候。

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