面对集中式缓存实现上的挑战，Redis交出的是何种答卷？聊聊Redis在分布式方面的能力设计

大家好，又见面了。

本文是笔者输出的缓存专栏系列内容，将会通过系列专题，讲清楚缓存的方方面面。如果感兴趣，欢迎关注以获取后续更新。

在本专栏前面的文章中，我们介绍了各种本地缓存框架，也知晓了本地缓存的常见特性与设计理念。在前两篇文章中，我们介绍了集中式缓存 Redis的一些主流特性与典型使用场景。现在我们来对比一下，分布式缓存相比于本地缓存，在实现层面需要关注的点有哪些不同。梳理如下：

维度	本地缓存	集中式缓存
缓存量	受限于单机内存大小，存储数据有限	需要提供给分布式系统里面所有节点共同使用，对于大型系统而言，对集中式缓存的容量诉求非常的大，远超单机内存的容量大小。
可靠性	影响有限，只有本进程使用，不会影响其他进程的可靠性。	作为整个系统扛压屏障，系统内所有节点共同依赖的通用服务，一旦集中式缓存出问题，会影响与其对接的所有业务节点，对系统的影响是致命性的。
承压性	承载单机节点的压力，请求量有限	承载整个分布式集群所有节点的流量，系统内业务分布式节点部署数量越多、业务体量越大，会导致集中缓存要承载的压力就越大，甚至是上不封顶的。

从上述几个维度的对比可以发现，同样是缓存，但集中式缓存所承担的使命是完全不一样的，业务对集中式缓存的存储容量、可靠性、承压性等方面的诉求也是天壤之别，不可等同视之。以Redis为例：

如何打破redis缓存容量受限于机器单机内存大小的问题？
如何使得redis能够扛住多方过来的请求压力？
如何保证redis不会成为单点故障源？

其实答案很简单，加机器！通过多台机器的叠加使用，达到比单机更优的效果 —— 现在业务系统的集群化部署，也都是采用的这个思路。Redis的分布式之路亦是如此，但相比于常规的业务系统分布式集群化构建更加复杂：

很多业务实现集群化部署会很简单，因为每个业务进程节点都是无状态的，只需要部署下然后通过负载均衡的方式对外提供请求应答即可。
Redis作为一个集中式缓存数据库，它是有状态的，不仅需要将进程分别部署在多个节点上，还需要将数据也分散存储在各个节点上，同时还得保证整个Redis集群对外是一个统一整体。

所以对于一个集中式缓存的分布式能力构建，必须要额外提供一些机制，来保障数据在各个节点上的安全与一致性，还需要将分散在各个节点上的数据都组成一个逻辑上的整体。

下面，我们以Redis作为集中式缓存的代表，来看下集Redis面对上述各种难题，交出的是怎样的答卷。

Reids部署方式的演进史

单机部署 —— 原始形态，最简单

单机部署只能算是一个开发或测试场景去小范围使用的场景，它与普通本地缓存无二，在可靠性与承压性上无法得到保证。

虽说Redis的性能很高，但俗话也说双拳难敌四手，单机性能再高，也无法抗住大规模集群中所有节点过来的并发请求。此外，单机部署还有个致命点在于其不具备高可用性，系统容易出现单点故障。

所以说，稍微正规点的项目，几乎不会有人天真到会用单机模式去部署线上使用。

主从（master-replica）

前面说过单机节点存在诸多问题，很少在生产环境上使用。在实际项目中，有些项目的存储容量要求其实并不是特别的高（比如常规的16G或者32G就已经足够使用），但是需要保证数据的可靠、并且支持大并发量请求，这种情况下，就可以选择主从部署的方式。

对于redis来说，一主两从是比较常见的搭配，如下所示：

主从模式按照读写分离的策略来提升整体的请求处理能力：

主节点(Master)同时对外提供读和写操作
从节点(Slave)通过replicate同步的方式，从主节点复制数据，保持自身数据与主节点一致
从节点只能对外提供读操作

当然，对于读多写少类的操作，为了提升整体读请求的处理能力，可以采用一主多从的方式：

所有的从节点都从主节点进行数据同步，这样会导致主节点的同步处理压力过大而成为瓶颈。为了解决这个问题，redis还支持了从slave节点分发的能力：

Redis的主从模式重点在于解决整体的承压能力，利用从节点分担读取操作的压力。但是其在容错恢复等可靠性层面欠缺明显，不具备自动的故障转移与恢复能力：

如果slave从节点宕机，整个redis依旧可以正常提供服务，待slave节点重新启动后，可以恢复从master节点的数据同步、然后继续提供服务。
如果master主节点宕机，则redis功能受损，无法继续提供写服务，直到手动修复master节点方可恢复。

当然，master节点故障后，也可以手动将其中一个从节点切换为新的master节点来恢复故障。而原先的master节点恢复后，需要手动将其降级为slave节点，对外提供只读服务。

实际使用的时候，手动故障恢复的时效无法得到保证，为了支持自动的故障转移与恢复能力，Redis在主从模式的基础上进行优化增强，提供了哨兵（Sentinel）架构模式。

哨兵（sentinel）

哨兵模式是在现代自动化系统里面常见的一种模式。比如特斯拉汽车就配置了哨兵模式，当车辆停车锁定并启动哨兵模式时，会通过车辆四周的摄像头持续的监控车辆四周的环境，如果发现异常则启动报警系统。

同样地，在软件架构领域，也可以通过设定一些主进程之外的辅助进程，充当“哨兵”的角色时刻监控着主服务，一旦主服务出现异常则进行报警或者自动介入辅助故障转移，以最大限度的保证系统功能的持续性。

Redis的哨兵模式，就是在主从模式的基础上，额外部署若干独立的哨兵进程，通过哨兵进程去监视者Redis主从节点的状态，一旦发现主节点宕机，则哨兵可以重新从剩余slave节点中推选一个新的节点并将其升级为master节点，以此保证整个系统功能可以正常使用。

比较典型的一个Redis sentinel部署场景是“一主二从三哨兵”的组合，如下：

哨兵可以准实时的监控着组网内所有的节点的状态信息，如果判定master节点宕机之后，所有的sentinel节点会一起推选出一个新的master节点。由于sentinel哨兵节点需要承担着master节点推选的责任，所以实施的时候要去sentinel节点个数必须为基数（比如3个、5个等），这是为了保证投票的时候不会出现平局的情况。

在哨兵模式下：

如果Redis的master节点宕机之后，Sentinel监控到之后，需要先判定确认master节点已经宕机，然后会从剩余存活的slave节点中投票选出一个新的节点作为master节点。
Sentinel监控到此前宕机的master节点重新恢复之后，会将其作为slave节点，挂到现有的新的master节点下面。

哨兵模式有效的解决了高可用的问题，保证了主节点的自动切换操作，进一步保障了Redis缓存节点的可靠性。但是，不管是哨兵模式还是主从模式，其增加的多台部署机器，都仅仅是扩展其承压能力与可靠性，并没有解决分布式场景下对于集中缓存容量的焦虑 —— 只能适用于数据量有限的场景。

成年人的世界总是贪婪的。如果我们既想要保证Redis的可靠性与承压性，还想要突破容量上的限制，就需要Redis的集群模式登场了。

集群（cluster）

Redis提供了去中心化的集群部署模式，集群内所有Redis节点之间两两连接，而很多的客户端工具会根据key将请求分发到对应的分片下的某一个节点上进行处理。

一个典型的Redis集群部署场景如下图所示：

在Redis集群里面，又会划分出分区的概念，一个集群中可有多个分区。分区有几个特点：

同一个分区内的Redis节点之间的数据完全一样，多个节点保证了数据有多份副本冗余保存，且可以提供高可用保障。
不同分片之间的数据不相同。
通过水平增加多个分片的方式，可以实现整体集群的容量的扩展。

按照Cluster模式进行部署的时候，要求最少需要部署6个Redis节点（3个分片，每个分片中1主1从），其中集群中每个分片的master节点负责对外提供读写操作，slave节点则作为故障转移使用（master出现故障的时候充当新的master）、对外提供只读请求处理。

集群数据分布策略

Redis Sharding（数据分片）

在Redis Cluster前，为了解决数据分发到各个分区的问题，普遍采用的是Redis Sharding（数据分片）方案。所谓的Sharding，其实就是一种数据分发的策略。根据key的hash值进行取模，确定最终归属的节点。

使用Redis Sharding方式进行数据分片的时候，当集群内数据分区个数出现变化的时候，比如集群扩容的时候，会导致请求被分发到错误节点上，导致缓存命中率降低。

如果需要解决这个问题，就需要对原先扩容前已经存储的数据重新进行一次hash计算和取模操作，将全部的数据重新分发到新的正确节点上进行存储。这个操作被称为重新Sharding，重新sharding期间服务不可用，可能会对业务造成影响。

一致性Hash

为了降低节点的增加或者移除对于整体已有缓存数据访问的影响，最大限度的保证缓存命中率，改良后的一致性Hash算法浮出水面。

通过一致性Hash算法，将所有的存储节点排列在首尾相接的Hash环上，每个key在计算Hash后会顺时针找到最近的存储节点存放。而当有新的分区节点加入或退出时，仅影响该节点在Hash环上顺时针相邻的后续一个节点。

当然咯，如果Hash圆环上的分区节点数太少，可能会出现数据在各个分片中分布不均衡的情况，也即出现数据倾斜。

为了解决这个问题，引入了虚拟节点的机制，通过增加虚拟节点，来实现数据尽可能的均匀分布在各个节点上。

上图中，A1、A2实际上都对应真实的A分区节点，而B1、B2则对应真实的B分区节点。通过虚拟节点的方式，尽可能让节点在Hash环上保持均分，实现数据在分区内的均分。

Hash槽

不管是原本的Hash取模，还是经过改良后的一致性Hash，在节点的新增或者删减的时候，始终都会出现部分缓存数据丢失的问题 —— 只是丢失的数据量的多少区别。如何才能实现扩展或者收缩节点的时候，保持已有数据不丢失呢？

既然动态变更调整的方式行不通，那就手动指定咯！Hash槽的实现策略因此产生。何为Hash槽？Hash槽的原理与HashMap有点相似，共有16384个槽位，每个槽位对应一个数据桶，然后每个Redis的分区都可以负责这些hash槽中的部分区间。存储数据的时候，数据key经过Hash计算后会匹配到一个对应的槽位，然后数据存储在该槽位对应的分片中。然后各个分区节点会与Hash槽之间有个映射绑定关系，由指定的Redis分区节点负责存储对应的Has槽对应的具体分片文件。