一文搞懂Redis架构演化之路( 四 ) _Redis

好，到这里我们先小结一下。
你的 Redis 从最简单的单机版，经过数据持久化、主从多副本、哨兵集群，这一路优化下来，你的 Redis 不管是性能还是稳定性，都越来越高，就算节点发生故障，也不用担心了。
Redis 以这样的架构模式部署，基本上就可以稳定运行很长时间了。
随着时间的发展，你的业务体量开始迎来了爆炸性增长，此时你的架构模型，还能够承担这么大的流量吗？
我们一起来分析一下：

数据怕丢失：持久化（RDB/AOF）
恢复时间久：主从副本（副本随时可切）
手动切换时间长：哨兵集群（自动切换）
读存在压力：扩容副本（读写分离）
写存在压力：一个 mater 扛不住怎么办？

可见，现在剩下的问题是，当写请求量越来越大时，一个 master 实例可能就无法承担这么大的写流量了。
要想完美解决这个问题，此时你就需要考虑使用「分片集群」了。
五、分片集群：横向扩展
什么是「分片集群」？
简单来讲，一个实例扛不住写压力，那我们是否可以部署多个实例，然后把这些实例按照一定规则组织起来，把它们当成一个整体，对外提供服务，这样不就可以解决集中写一个实例的瓶颈问题吗？
所以，现在的架构模型就变成了这样：

文章插图
现在问题又来了，这么多实例如何组织呢？
我们制定规则如下：

每个节点各自存储一部分数据，所有节点数据之和才是全量数据
制定一个路由规则，对于不同的 key，把它路由到固定一个实例上进行读写

数据分多个实例存储，那寻找 key 的路由规则需要放在客户端来做，具体就是下面这样：

文章插图
这种方案也叫做「客户端分片」，这个方案的缺点是，客户端需要维护这个路由规则，也就是说，你需要把路由规则写到你的业务代码中。
如何做到不把路由规则耦合在客户端业务代码中呢？
继续优化，我们可以在客户端和服务端之间增加一个「中间代理层」，这个代理就是我们经常听到的 Proxy，路由转发规则，放在这个 Proxy 层来维护。
这样，客户端就无需关心服务端有多少个 Redis 节点了，只需要和这个 Proxy 交互即可。
Proxy 会把你的请求根据路由规则，转发到对应的 Redis 节点上，而且，当集群实例不足以支撑更大的流量请求时，还可以横向扩容，添加新的 Redis 实例提升性能，这一切对于你的客户端来说，都是透明无感知的。
业界开源的 Redis 分片集群方案，例如 Twemproxy、Codis 就是采用的这种方案。

文章插图
这种方案的优点在于，客户端无需关心数据转发规则，只需要和 Proxy 打交道，客户端像操作单机 Redis 那样去操作后面的集群，简单易用。
架构演进到目前为止，路由规则无论是客户端来做，还是 Proxy 来做，都是「社区」演进出来的分片解决方案，它们的特点是集群中的 Redis 节点，都不知道对方的存在，只有客户端或 Proxy 才会统筹数据写到哪里，从哪里读取，而且它们都依赖哨兵集群负责故障自动切换。
也就是说我们其实就是把多个孤立的 Redis 节点，自己组合起来使用。
Redis 在 3.0 其实就推出了「官方」的 Redis Cluster 分片方案，但由于推出初期不稳定，所以用的人很少，也因此业界涌现出了各种开源方案，上面讲到的 Twemproxy、Codis 分片方案就是在这种背景下诞生的。
但随着 Redis Cluster 方案的逐渐成熟，业界越来越多的公司开始采用官方方案（毕竟官方保证持续维护，Twemproxy、Codis 目前都逐渐放弃维护了），Redis Cluster 方案比上面讲到的分片方案更简单，它的架构如下。

文章插图
Redis Cluster 无需部署哨兵集群，集群内 Redis 节点通过 Gossip 协议互相探测健康状态，在故障时可发起自动切换。
另外，关于路由转发规则，也不需要客户端自己编写了，Redis Cluster 提供了「配套」的 SDK，只要客户端升级 SDK，就可以和 Redis Cluster 集成，SDK 会帮你找到 key 对应的 Redis 节点进行读写，还能自动适配 Redis 节点的增加和删除，业务侧无感知。
虽然省去了哨兵集群的部署，维护成本降低了不少，但对于客户端升级 SDK，对于新业务应用来说，可能成本不高，但对于老业务来讲，「升级成本」还是比较高的，这对于切换官方 Redis Cluster 方案有不少阻力。