干货 | 携程Redis治理演进之路（二）

作者简介

 

本文为联合撰稿，作者团队包括：布莱德，携程技术专家；向晨，携程数据库专家；骋成，携程技术专家；小峰，携程高级软件工程师。

一、背景

携程Redis集群规模和数据规模在过去几年里快速增长，我们通过容器化解决了Redis集群快速部署的问题，并根据实际业务进行的一系列尝试，比如二次调度，自动化漂移等，在内存超分的情况下保证了宿主机的可靠性。

扩缩容方面，我们主要通过垂直扩缩容的方式解决Redis集群容量的问题，但随着集群规模扩大，这种方式逐渐遇到了瓶颈。一方面，单个Redis实例过大，会带来较大的运维风险和困难；另一方面，宿主机容量有上限，不能无止境的扩容。考虑到运维便利性和资源利用率的平衡，我们希望单个Redis实例的上限为15GB。但实际操作中却很难做到：a. 某些业务发展很快，经常性需要给Redis进行扩容，导致单个实例大小远超15GB；b. 一些业务萎缩，实际使用量远低于初始申请的量，造成资源的浪费。

如何有效控制Redis实例大小呢？接下来本文将带着这个问题，逐步讲解携程Redis治理和扩缩容方面的演进历程。

 

二、Redis水平扩分拆

在携程开始使用Redis很长一段时间里，一直只有垂直扩缩容，原因有两点：

第一，一开始业务规模比较小，垂直扩缩容可以满足需求。垂直扩缩容对于Redis来说只是Maxmemory的配置更改，对业务透明；

第二，水平拆分/扩缩容的实现难度和成本较高。

之前文章《携程Redis治理演进之路》中已经提到，携程访问所有的Redis集群使用的是自主研发的CRedis，而部署在应用端的CRedis通过一致性hash来访问实际承载数据的Redis实例。但一致性hash是无法支持直接水平扩缩容的。因为无论增加一个节点或者删除一个节点，都会导致整个hash环的调整。

图1

如图所示，假设原始有4个分片（图1）。当添加一个节点后，它会导致某一部分的key本来是写到nodeC上而现在会被写到nodeE上，也就是无法命中之前的节点。从客户端的角度来看，key就像是丢失了。而变动的节点越多，key丢失的也越多，假设某个集群从10分片直接添加到20分片，它直接会导致50%的key丢失。删除一个节点同理，就不再赘述。

因此尽管一致性hash是个比较简单优秀的集群方案，但无法直接水平扩容一直困扰着运维和架构团队。为此，CRedis团队在2019年提出了水平拆分的方案。

CRedis水平分拆的思路比较朴素，因为在一致性hash同一个水平位置增加节点会导致数据丢失&#