redis集群类型

• [主从复制模式](# 主从复制模式)
• Sentinel（哨兵）模式
• Cluster 模式

主从复制模式

主从复制的作用

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。

为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。

为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

总结：引入主从复制机制的目的有两个

• 一个是读写分离，分担 “master” 的读写压力
• 一个是方便做容灾恢复

• 从数据库启动成功后，连接主数据库，发送 SYNC 命令；
• 主数据库接收到 SYNC 命令后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令；
• 主数据库 BGSAVE 执行完后，向所有从数据库发送快照文件，并在发送期间继续记录被执行的写命令；
• 从数据库收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主数据库快照发送完毕后开始向从数据库发送缓冲区中的写命令；
• 从数据库完成对快照的载入，开始接收命令请求，并执行来自主数据库缓冲区的写命令；（从数据库初始化完成）
• 主数据库每执行一个写命令就会向从数据库发送相同的写命令，从数据库接收并执行收到的写命令（从数据库初始化完成后的操作）
• 出现断开重连后，2.8之后的版本会将断线期间的命令传给从数据库，增量复制。
• 主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。Redis 的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

主从复制优缺点

主从复制优点

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离；
• 为了分载 Master 的读操作压力，Slave 服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成；
• Slave 同样可以接受其它 Slaves 的连接和同步请求，这样可以有效的分载 Master 的同步压力；
• Master Server 是以非阻塞的方式为 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求；
• Slave Server 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据；

主从复制缺点

• 每个节点都是全量数据，内存利用率低，浪费资源
• 主节点挂掉时，有可能导致主从数据不一致
• 主节点挂掉后，虽然从节点可继续查询，但是主节点不能提供写入服务
• 主节点挂掉后需要人工介入
• 写入压力在一个节点
• 如果多个 Slave 断线了，需要重启的时候，尽量不要在同一时间段进行重启。因为只要 Slave 启动，就会发送sync 请求和主机全量同步，当多个 Slave 重启的时候，可能会导致 Master IO 剧增从而宕机。
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂；

哨兵模式

哨兵模式是在主从模式的基础上，增加了由一个或多个哨兵组成的哨兵集群来监视主从模式的运行状态，解决主节点挂掉时无法继续对外提供写入服务的问题。一般会用奇数个哨兵节点，因为每个哨兵都会监视集群中节点的状态，如果主节点挂掉了，哨兵会进行投票，将某个从节点提升为主节点接续对外提供服务，从而达到高可用。客户端连接哨兵，哨兵对外提供redis服务地址的发现。

优点

1. 实现了高可用，部分节点挂掉依然能对外提供全部服务
2. 出现问题，自动切换，无需人工介入

缺点

1. 依然存在内存利用率不高，每个节点都是全量数据的问题
2. 部署相对复杂，节点较多，不确定性增加
3. 写入压力依然集中在一个节点

Cluster 集群模式（Redis官方）

Redis Cluster是一种服务器 Sharding 技术，3.0版本开始正式提供。

Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

Redis 集群没有使用一致性 hash，而是引入了哈希槽【hash slot】的概念。

Redis 集群有16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽。集群的每个节点负责一部分hash槽，举个例子，比如当前集群有3个节点，那么：

• 节点 A 包含 0 到 5460 号哈希槽
• 节点 B 包含 5461 到 10922 号哈希槽
• 节点 C 包含 10923 到 16383 号哈希槽

这种结构很容易添加或者删除节点。比如如果我想新添加个节点 D ， 我需要从节点 A， B， C 中得部分槽到 D 上。如果我想移除节点 A ，需要将 A 中的槽移到 B 和 C 节点上，然后将没有任何槽的 A 节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

优点

1. 写入操作会被分配到不同的节点，提高了写入效率
2. 数据是分片保存到了不同的主从节点，内存利用率较高，扩展性好
3. 高可用，除非其中一个主从集群的节点都挂掉，否则任何一个节点挂掉都能继续对外提供服务

为什么redis不用一致性哈希

1、一致性哈希的节点分布基于圆环，无法很好的手动设置数据分布，比如有些节点的硬件差，希望少存一点数据，这种很难操作。而哈希槽可以很灵活的配置每个节点占用哈希槽的数量

一致性哈希的某个节点宕机或者掉线后，当该机器上原本缓存的数据被请求时，会从数据源重新获取数据，并将数据添加到失效机器后面的机器，这个过程被称为 “缓存抖动” ，而使用哈希槽的节点宕机，会导致一定范围内的槽不可用，只能通过主从复制加哨兵模式保证高可用。

真实基于一致性哈希的特点，当某台机器宕机时，极易引起雪崩，如上述介绍中删除节点。

Redis Cluster的槽位空间是可以用户手动自定义分配的，类似于 windows 盘分区的概念，可以手动控制大小。

相对于哈希槽，一致性哈希算法更复杂

为什么Redis Cluster的Hash Slot 是16384？

我们知道一致性hash算法是2的16次方，为什么hash slot是2的14次方呢？
作者antirez的回复

---

在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2

• 8 (8 bit) * 1024(1k) = 16K），也就是说使用2k的空间创建了16k的槽数。 虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) *1024(1k)=65K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

参考文章：https://segmentfault.com/a/1190000022808576。https://segmentfault.com/a/1190000022808576