Redis 集群的合纵与连横

以前一篇写了关于 Redis 的性能，这篇就写写我认为比性能更重要的扩展性方面的主题。

若是再给我一次回到好几年前的机会，对于使用 Redis 我一开始就要好好考虑未来的扩展问题。就像咱们作数据库分库分表，一旦决策了分库分表，一般一次就会分到位，好比搞上 8 或 16 个库，每一个库再分 256 或 1024 个表。无论未来业务再怎么发展，基本这个量级的分片都足够应对，并且底层库能够作成逻辑的，扛不住时再换成物理的，对应用方彻底透明，没有数据迁移的烦恼。

而 Redis 其实也提供了相似的逻辑库概念，每一个 Redis 实例都有 0 到 15 号独立的逻辑库空间。当咱们早期机器资源紧张而业务量又不大时，能够好好根据业务把不一样的数据放在的单一实例的不一样编号逻辑库上。这是一种垂直切分方式，也能够用水平方式，把 0 到 15 号逻辑库当成 16 个分片来用，只是这种用法可能对 Client 库有些要求。

总之好几年前咱们都没有这样，当时物理机资源紧张，为了考虑不远未来的业务扩张，因此在有限的资源下决定尽量的分片。但也没分太多，大约 10 片吧，多了运维成本也高。感受按 Redis 的性能这一组分片最大承载几十万每秒的 OPS 估计能支撑很长时间的发展了。那 10 片怎么部署呢？因为每一个 Reids 实例只能利用一个核，当时的服务器大概是 16 核，全放一台机也能够。当时咱们正好有 10 台物理机，因此很天然的每台放了一个实例，但 Redis 只能用一个核，太浪费了。因此每台物理机上除了部署 Reids 还要部署应用服务，后来领悟到这又是一个错误的部署方式（背景音乐：多么痛的领悟）。

一台 PC Server 的硬件可靠性大约是 99.9%，Redis 做为一个应用全局共享的关键服务分红 10 片放在十台 PC Server 上。实际上致使总体系统可靠性还下降了一个量级，变成了两个 9。由于任何一台 PC Server 挂了均可能致使全局系统故障。然而当初没有多余的机器资源，为了提升可靠性，必须对 Redis 作主备，惟一的办法就是交叉主备，因此部署结构大概相似下面这样。

后来，随着业务发展流量变得愈来愈大，Redis 内存占用愈来愈多，并且开始出现一些诡异的故障现象。好比出现瞬时 Redis 大量链接和处理超时，应用业务线程被阻塞，致使服务拒绝，过一段时间可能又自动恢复了。这种瞬时故障很是难抓现场，一天来上几发就会给人业务不稳定的感觉，而通常基础机器指标的监控周期在分钟级。瞬时故障可能发生在监控的采集间隙，因此只好上脚本在秒级监控日志，发现瞬时出现大量 Redis 超时错误，就收集当时应用的 JVM 堆栈、内存和机器 CPU Load 等各项指标。终于发现瞬时故障时刻 Redis 机器 CPU Load 出现瞬间飙升几百的现象，应用和 Redis 混合部署时应用可能瞬间抢占了所有 CPU 致使 Redis 没有 CPU 资源可用。而应用处理业务的逻辑又可能须要访问 Redis，而 Redis 又没有 CPU 资源可用致使超时，这不就像一个死锁么。搞清楚了缘由其实解决方法也简单，就是分离应用和 Redis 的部署，各自资源隔离，自此咱们的 Redis 集群发展开始走上一条合纵与连横的道路。

合纵

分离应用和 Redis 的部署后，关于物理机资源的有一个尴尬点就是 Redis 单线程机制带来的。当时一台 PC Server 16 核，内存 16 G，你想多利用核就要多部署实例，但每一个实例分到的内存又很少。最终咱们一台物理机只部署 2 个实例，由于业务发展对内存的需求强过对 CPU 的利用，因此调整后的部署模型变成下面这样。

这样每一个 Redis 实例能分到的内存是小于 8G 的（还要给系统留一点不是）。随着业务发展，一开始是 2G，很快 4G 而后 6G 就到了单机内存瓶颈，下一步只能分一个实例出去，每一个实例独享单机内存。纵向扩容在操做性上是最简单的，在另一台机器上先挂一个从分片，同步复制完成后，通知 Client 端切换链接而分片 Hash 规则仍是不变。这个过程会有短暂的（下图 2-5 步这个过程程序执行的时间窗口）写丢失，在业务上是可接受的。

独享了更大内存，咱们就能够继续纵向扩内存，但扩到了 12G 后就基本到顶了，即使还有更大内存的物理机也不宜再扩大单分片的内存了。主要缘由是由于 Redis 的主从复制致使的服务中断，当初 Redis 版本是 2.4，直到 2.8 才有增量的主从复制。即便 2.8 主从复制依然可能在断链长时间后致使全量复制，虽然官方文档号称主从复制不中断服务，但实际每次全量复制 dump 内存时是阻断了主线程执行。这个阻断时间在 12G 内存时大概有一分多钟， 继续纵向扩大内存会致使更长时间的阻断，在业务上不可接受，合纵之路也走到头了。

连横

为了对业务作到无缝透明的扩容，只能走横向发展的道路。而 Redis 官方的 Cluster 方案一直跳票，迟迟出不来，你们的业务都在快速发展，等不及啊。因此在横向扩展上演变出了两种方案，一种是代理模式，利用引入中间 Proxy 来向应用层屏蔽后端的集群分布。业界最先是 Twitter 开源的 Twemproxy 采用了这种模式，后来豌豆荚开源的 Codis 进一步在运维可操做性上完善了这种模式。主要是在扩容方面尽量的作到业务无感知，思路就是前端引入 Proxy 隔离应用层，后端改造 Redis 引入 Slot（有些也叫 Buket）来分组 key。应用层访问时基于算法将 key 先映射到 Slot 再映射到具体分片实例，大概以下面这样。

F(key) -> Slot -> Instance

Redis 中的 key 按 Slot 来组织，平滑扩容时好比加分片后，按 Slot 为单位迁移，这一般须要改造 Redis 源码来支持。这个模式的架构示意图以下所示。

引入 Proxy 是牺牲了少许性能来换取了对应用的透明和更好的扩展性。另外一种方案是基于 Smart Client 免代理，但对应用有必定的侵入性，本质上就是把 Proxy 的功能放到了 Client。

至于采用哪一种方案就是仁者见仁、智者见智了，须要根据实际状况去考虑。不过我的认为基于代理的方案更灵活些，并且可在 Proxy 层能作的事情比 Client 要多，但对 Proxy 的实现要求也更高。无论上面哪一种方案都采用了中心化的控制方式，中心化对简化运维操做是有好处的，并且能方便作到集群全局的管理。

Redis Cluster 终于迟迟推出后，采用了与中心化不一样的思路，并且设计目标更追求性能，因此是依赖 Smart Client 的方式。而 Redis Server 的实现仍是使用了 Slot 方式默认最大 16 * 1024 = 16384 个 Slot，因此理论集群最大就是这么多个实例，实际不大可能须要这么大。采用 Gossip 消息来同步集群配置，基于投票机制来进行主从 Failover 发现和自动切换。从目前已经推出的版本和功能来看，做者是在往一个纯 Smart Cluster 方向发展，但显然目前的版本还不成熟。好比自动发现、集群智能再平衡等功能都没有，还依赖人工操做。并且非中心化的集群相比中心化集群的可预测性和操做性都要差很多，其在真实的应用案例，除了在网易有道有人分享了一个非关键类场景，还没见过比较有分量的成熟案例。因此 Redis Cluster 的道路恐怕还在路漫漫其修远兮，吾将上下而求索的阶段。

总结

前面回顾了 Redis 集群发展的历程，从合纵到连横实际是一个从业务垂直切分到平台服务化的过程。至于到底应该采用什么样的集群模式，可能须要好好结合自身的业务发展阶段、团队能力和企业环境去分析取舍了。没有最好的，只有合适的。

参考

[1] antirez. Redis Cluster Specification
[2] 黄东旭. 分布式 Redis 架构设计和踩过的那些坑们
[3] 西代零零发. 全面剖析 Redis Cluster 原理和应用
[4] 西代零零发. Redis Cluster 架构优化
[5] 杨肉. Redis Cluster 使用经验

你还能够看

Redis 的性能幻想与残酷现实