前言

之前简单分享了一下单机版Redis。包括：

为什么用 Redis 以及为什么不用 RedisRedis 为什么这么快Redis 的数据结构Redis 单线程吞吐量高的原因

单机版 Redis 响应快、支持的并发量高，如果有持久化的内存，甚至还能做到数据不丢失。那我们可以直接使用单机版 Redis 作为数据库吗？

假设我们使用单机版 Redis 作为存储介质。Redis 一般分为两种用途，缓存和持久化数据库。

我们先看最常见的一种情况，断电/重启：

业务数据库： 使用持久化内存可以保证重启后数据不丢失。但是断电的过程中整个业务没有数据源就会瘫痪掉。缓存： 如果缓存断电瘫痪，倒不至于会对业务造成直接瘫痪，毕竟业务数据库中有完整的数据。如果 Redis 宕机，就会导致缓存雪崩——所有缓存都失效，所有的请求都是直接打到数据库，导致数据库压力激增，导致服务响应时间增加。

在断电情况下，单机 Redis 作为业务数据库肯定是不满足条件的；作为缓存，如果数据量小、请求量少的话，并不是很影响业务使用（这种场景也没有用缓存的必要）。

那如果不考虑重启的情况，单机 Redis 就没问题了吗？

数据量、访问量小的情况下，貌似确实不会有什么问题，我们还是考虑数据量、访问量大的情况。

比如现在有一个单机 redis， 需要存储几亿个key。当 Redis 持久化时，如果数据量增加，需要的内存也会增加，主线程 fork 子进程时就可能会阻塞。即使在内存、CPU资源充足的情况下，一次数据备份就要消耗很长时间，导致 Redis 的服务不可用。

不过，如果你不要求持久化保存 Redis 数据，那么，增加cpu的硬件性能和内存容量会是一个不错的选择。但是这样又有第二个问题，就是硬件成本问题：一块128G的内存条的价格远大于四块32G 的内存条的价格之和，cpu也是同理。硬件的成本会随着性能的不断提高呈指数上升

综上所述，单机版 Redis 主要存在以下两个问题：

可用性（断电后，业务不可用）数据臃肿（单机CPU对大量数据的操作） 备份阻塞导致服务不可用 成本指数增长

那怎么办呢？单机不够用，就多加几台机器嘛！下面我们来看一下 Redis 提供的在多机环境下几种常见的资源使用策略，看看能否解决上述的两个问题

一、主从同步(Master-Slave)

主从同步就是，多个 Redis 节点，一个主节点（master），多个副节点（slave）。读请求会发送到各个节点，写请求只会发给 master，然后 slave 定时会从 master 拉取新增的写操作以保证数据的一致性。

那如何从单机版加一个 slave 节点过渡到主从模式呢？ 例如，现在有实例 1（ip：192.168.19.3）和实例 2（ip：192.168.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：

replicaof 192.168.19.3 6379

第一次请求到 master 的 RDB 文件全量同步，在 RDB 文件内容之后的操作都是增量同步进行。

之后就是重复1和3的过程。

二、哨兵机制(Sentinel)

上面讲的主从同步只是保证了 Redis 的数据有及时备份。可以分担一部分主库的访问压力，以及保证了从库的可用性。但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。

哨兵（Sentinel）就是为了解决这个问题而产生的。它实现了主从库自动切换的关键机制，它有效地解决了主从复制模式下故障转移的三个问题。

主库真的挂了吗？该选择哪个从库作为主库？怎么把新主库的相关信息通知给从库和客户端呢？

下面我们就从这三个问题来看 Sentinel 对应的三种职能，监控、选主和通知。

2.1 监控

哨兵需要判断主库是否处于下线状态。这里要先说两个概念，即主观下线和客观下线，

哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库响应超时了，那么，哨兵就会先把它标记为“主观下线”。如果检测的是从库，那么，哨兵简单地把它标记为主观下线就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。

如果检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”。因为很有可能存在这么一个情况：那就是哨兵误判了，其实主库并没有故障。可是，一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算和通信开销。

那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断的时候，经常会和家人或朋友一起商量一下，然后再做决定。哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。

“客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。

2.2 选主

当哨兵们判断主库客观下线的时候，就要开始下一个决策过程了，即从许多从库中，选出一个从库来做新主库。

一般来说，我把哨兵选择新主库的过程称为“筛选 + 打分”。

筛选条件： 网络连接状态（现在 + 之前）。在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

打分：

首先，优先级最高的从库得分高。用户可以手动设置从库的优先级。其次，和旧主库同步程度最接近的从库得分高。最后，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

哨兵也是集群模式，也要保证服务的可用性，所以也会有相应的保证机制。这里不在本篇的 Redis 集群讨论范围之内，所以就不展开描述了。

三、 Redis Cluster

看到这里，还记得我们一开始发现的 Redis 单机版的两个问题吗？可用性和数据臃肿。

上面主从模式 + 哨兵模式足以保证 Redis 服务的可用性，但是看起来并没有解决数据臃肿的问题， Redis Cluster 就为我们提供了解决这个问题的方案。

3.1 数据切片

切片集群，也叫分片集群，就是指启动多个 Redis 实例组成一个集群，然后按照一定的规则，把收到的数据划分成多份，每一份用一个实例来保存。

这样单份数据可以缩小到备份不影响该实例的主进程，而且还可以解决硬件成本问题。

那数据都分散了，用户需要查某一条数据，Redis 怎么知道这条数据在哪个实例呢？

我们要先弄明白切片集群和 Redis Cluster 的联系与区别。 切片集群是一种保存大量数据的通用机制，这个机制可以有不同的实现方案。 Redis Cluster 方案采用 hash 槽（Hash Slot，接下来我会直接称之为 Slot），来处理数据和实例之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个 hash 槽，这些 hash 槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个 hash 槽中。具体的映射过程分为两大步：

首先根据键值对的 key，按照CRC16 算法计算一个 16 bit 的值；然后，再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的 hash 槽。

关于 CRC16 算法，不是我们讨论的重点。我们只需要每一个 key 都能算出来一个 0~16383 的数就好。

每一个 0~16383 的数被称为一个slot（槽）。一个 Redis 实例有多个槽，集群中的所有 Redis 实例的槽加起来一定等于 16384。换句话说，在手动分配 hash 槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。

3.2 客户端如何定位数据？

在定位键值对数据时，它所处的 hash 槽是可以通过计算得到的，这个计算可以在客户端发送请求时来执行。但是，要进一步定位到实例，还需要知道 hash 槽分布在哪个实例上。

Redis 实例会把自己的 hash 槽信息发给和它相连接的其它实例，来完成 hash 槽分配信息的扩散，Redis集群采用P2P的Gossip(流言)协议， Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息，这种方式类似流言传播 当实例之间相互连接后，每个实例就有所有 hash 槽的映射关系了。相当于每一个实例都有一份 slot 与实例地址的映射关系表。

当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有这个键值对映射的 hash 槽，那么，这个实例就会给客户端返回下面的 MOVED 命令响应结果，这个结果中就包含了新实例的访问地址。

GET hello:key(error) MOVED 13320 192.168.19.5:6379

如上图，用户连接上任意一个 Redis 实例，都可以查询集群中所有的key。比如连上实例2，查询key = “hello”。实例2会根据key计算 hash 槽的值。

如果槽就在实例2上，则直接查询结果返回；如果不在实例2上，则返回存在key的实例地址。

客户端也会缓存请求过的key对应实例的地址。

如果实例槽有变动，比如手动增删了几个实例，剩下的实例还是可以自动同步新的 hash 槽对应的实例位置。

3.3 实际应用

Redis Cluster 模式解决了数据臃肿的问题，但是单独的 Redis Cluster 模式并没有可用性，如果任意一个实例断电或者断网，这个实例所有 hash 槽的数据就会处于不可用的状态。

所以在实际使用场景下，上述的三种集群模式都会结合起来。

到这里我们就解决了开篇提出的两个问题。

保证可用性： cluster node 中的主从同步和哨兵选举机制避免数据臃肿：cluster node 集群的数据切片四、小结

开篇我们提出的单机版 Redis 作为数据库的两个弊端。然后介绍了 Redis 官方的集群方案分别是如何解决这两个弊端的。

其实除了 Redis 官方提供的集群方案，也有很多优秀的开源 Redis 集群方法。 比如：

推特的 twemproxy

国内豌豆荚出品的 Codis

这两种开源方案和 Redis 官方的集群方案最大的区别就是数据节点的管理方式。

Redis 是去中心化，hash 槽和节点的映射每个节点都会有保存，通过 Gossip 协议传播；这两种方案是中心化。有单独的代理节点管理hash 槽和节点的映射。

那去中心化和中心化我们又该如何选择呢？