引言

前面我们已经聊过的主从同步（复制）和哨兵机制，这期我们来聊Redis的集群模式。但是在超大规模的互联网应用中，业务规模不断扩展，用户量持续增多时，原有的主从+哨兵机制已经不满足我们的需求了。如：性能问题，数据量过多、并发量过高导致Redis服务器响应太慢。

自古功夫出少林

如果把Redis比作江湖里的门派，少林寺作为武林中最有威望的名门正派，提供了武功秘籍（缓存数据）的存储服务。由于少林存储的可用性做的很好，武功秘籍几乎不会丢失。而且，每次去获取武林同道的秘籍时，响应也很快，所以少林威望不断提升，后得千古美誉：自古功夫出少林。 少林的武功秘籍存储方案为什么这么稳定呢？这得从头说起。

累坏的掌门人

在武林大会3.0之前，已经有很多武林同道在少林寺存取武功秘籍了，而少林掌门作为权力的中心，不仅披星戴月和外宾打交道（Client请求），还得在管理物资之余（数据存储和输出）给副掌门做业务培训（数据备份）。虽然在武林大会2.8时，少林和武当一样，已经新增了哨兵部门，从此不用担心掌门嗝屁的问题。但掌门人日理万机，应接不暇，还是把头发都愁掉了！为了掩饰尴尬，从此少林弟子不准留头发。

Redis集群模式的引入

随着使用Redis的互联网公司越来越多，诸如Facebook、Twitter、Google等大厂，在实际的运用和探索过程中，发现原有的主从+哨兵架构已经无法满足他们系统的需求。因此，Redis团队在经过大量的调研和开发后，正式发布了Redis集群模式，以解决超大规模应用场景下的性能、可用性和扩展性问题。 Redis集群模式是一个去中心化的架构，它将数据分片存储在多个节点上，每个节点都是独立的，并且与其他节点对等。这样就避免了单点故障问题，也提高了系统的整体性能。

Redis集群模式的优点

高性能：由于数据分片存储，集群模式可以充分利用多核CPU的优势，提高系统的整体性能。 高可用：集群模式采用去中心化的架构，每个节点都是独立的，如果某个节点故障，不会影响其他节点的正常运作。 可扩展：集群模式可以轻松地添加或删除节点，以满足业务需求的增长或缩减。 数据一致性：集群模式使用一致性哈希算法，确保数据分布在整个集群中，并且每个写入操作都会同步到所有节点。

Redis集群模式的实现原理

Redis集群模式使用一种称为"哈希槽"（Hash Slot）的概念来分片数据。哈希槽是一个0到16383之间的数字，每个哈希槽都存储一部分数据。 当客户端向集群发送写请求时，集群会根据键的哈希值计算出该键应该存储在哪一个哈希槽上。集群会将写请求转发到负责该哈希槽的节点上。 当客户端向集群发送读请求时，集群也会根据键的哈希值计算出该键应该存储在哪一个哈希槽上。集群会将读请求转发到负责该哈希槽的节点上。 如果负责该哈希槽的节点故障，集群会自动将该哈希槽上的数据重新分配到其他节点上。这样就保证了数据的可用性，不会因为某个节点故障而导致数据丢失。

Redis集群模式的部署

Redis集群模式的部署相对复杂，需要涉及到多个节点的配置和管理。以下是一些部署Redis集群模式的步骤： 1. 创建多个Redis节点。 2. 配置每个节点的集群信息，包括集群名称、节点ID和初始集群成员。 3. 启动所有节点，并等待集群形成。 4. 使用redis-cli工具连接到集群，并执行命令来管理集群。

Redis集群模式的监控

Redis集群模式提供了多种监控工具，可以帮助运维人员监控集群的运行状态。这些工具包括： redis-cli：可以连接到集群并执行命令来获取集群信息。 Redis Sentinel：可以监控集群的运行状态并自动故障转移。 Grafana：可以创建仪表盘来可视化集群的运行指标。

Redis集群模式的最佳实践

以下是一些使用Redis集群模式的最佳实践： 使用一致性哈希算法来分片数据。 使用哨兵来监控集群的运行状态并自动故障转移。 使用持久化机制来保护数据，避免数据丢失。 定期备份集群数据。 使用合适的集群大小和配置。

总结

Redis集群模式是一个去中心化的架构，它将数据分片存储在多个节点上，每个节点都是独立的，并且与其他节点对等。这种架构具有高性能、高可用和可扩展的优点。 Redis集群模式适用于超大规模的互联网应用场景，可以解决主从+哨兵架构无法满足的性能、可用性和扩展性问题。 本文介绍了Redis集群模式的优点、实现原理、部署步骤、监控工具和最佳实践。希望本文能帮助您了解Redis集群模式，并将其应用到您的实际项目中。

---

调研Redis高可用两种方案

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

作者 codedump 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 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的高可用（主从、哨兵、集群）

所谓的高可用，也叫 HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式： 主从模式 ， 哨兵模式和集群模式 。

Redis 提供了 Redis 提供了复制(replication)功能，当一台 redis 数据库中的数据发生了变化，这个变化会被自动地同步到其他的 redis 机器上去。

Redis 多机器部署时，这些机器节点会被分成两类，一类是主节点（master 节点），一类是从节点（slave 节点）。一般 主节点可以进行读、写操作 ，而 从节点只能进行读操作 。一个主节点可以有多个从节点，但是一个从节点只会有一个主节点，也就是所谓的 一主多从结构 。

· 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离;

· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求;

· Slave 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis 则返回同步之前的数据。

· Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复;

· 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后面还会引入数据不一致的问题，降低了系统的可用性;

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂;

· Redis 的主节点和从节点中的数据是一样的，降低的内存的可用性

实际生产中，我们优先考虑哨兵模式。这种模式下，master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。

在主从模式下，redis 同时提供了哨兵命令redis-sentinel，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。一般为了便于决策选举，使用 奇数个哨兵 。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:

· 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器;

· 然而一个哨兵进程对 Redis 服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多种哨兵模式。

哨兵很像 kafka 集群中的 zookeeper 的功能。

· 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

· 主从可以自动切换，系统更健壮，可用性更高。

· 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法，而是使用 slots 插槽 。

Redis 哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0 上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容；每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。 通讯时使用特殊的端口号，即对外服务端口号加 。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 。nodes 之间的通信采用特殊的二进制协议。

对客户端来说，整个 cluster 被看做是一个整体，客户端可以连接任意一个 node 进行操作，就像操作单一 Redis 实例一样， 当客户端操作的时候 key 没有分配到该 node 上时，Redis 会返回转向指令，指向正确的 node，这有点儿像浏览器页面的 302 redirect 跳转。

根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。

在 Redis 的每一个节点上，都有这么两个东西， 一个是插槽（slot），它的的取值范围是：0-， 可以从上面执行的结果看到这 个 slot 在三个 master 上的分布。还有一个就是 cluster，可以理解为是一个集群管理的插件，类似的哨兵。

当我们的存取的 Key 到达的时候，Redis 会根据 crc16 的算法对计算后得出一个结果，然后把结果和 求余数，这样每个 key 都会对应一个编号在 0- 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用， redis-cluster 集群引入了主从模式 ，一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时，如果半数以上的主节点与 master 1 通信超时，那么认为 master 1 宕机了，就会启用 master 1 的从节点 slave 1，将 slave 1 变成主节点继续提供服务。

如果 master 1 和它的从节点 slave 1 都宕机了，整个集群就会进入 fail 状态，因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉，无论是否有 slave，集群都会进入 fail 状态。

redis-cluster 采用去中心化的思想 ，没有中心节点的说法，客户端与 Redis 节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

对 redis 集群的扩容就是向集群中添加机器，缩容就是从集群中删除机器，并重新将 个 slots 分配到集群中的节点上（数据迁移）。

扩缩容也是使用集群管理工具 。

扩容时，先使用 add-node将新的机器加到集群中，这是新机器虽然已经在集群中了，但是没有分配 slots，依然是不起做用的。在使用 reshard进行分片重哈希（数据迁移），将旧节点上的 slots 分配到新节点上后，新节点才能起作用。

缩容时，先要使用 reshard移除的机器上的 slots，然后使用 add-del移除机器。

采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;

可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;

高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;

降低运维成本，提高系统的扩展性和可用性。

Cluster 是无中心节点的集群架构，依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG 通讯，不必须要的流量占用了大量的网络资源。虽然 Reds4.0 对此进行了优化，但这个问题仍然存在。

2.数据迁移问题

Redis Cluster 可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。

而 Redis 为了保证迁移的一致性，迁移所有操作都是同步操作 ，执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小 Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。

主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

集群模式：数据量比较大，QPS 要求较高的时候使用。 Redis Cluster 是 Redis 3.0 以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。