给我10分钟，无感知搞定Redis集群扩缩容( 二 ) 一、背景携程Redis集群规模和数

三、Redis水平扩缩容
1、设计思路

文章图片
图4
既然缩分片比较困难，我们首先想到的是业务双写集群的方法，也就是业务同时双写2个新老集群，新老集群的分片数是不一样的，并且大小配置也不一样。比如之前申请4个分片现在发现资源过剩，让业务创新申请一个新的2个分片的集群，由业务来控制灰度写哪个集群（图4）。最终会迁移到新集群上，而新集群大小是满足当前业务需求的，从而达到了缩容的目的。
双写集群的方案虽然解决我们部分的问题，但对于业务的侵入比较深，此外由于双写集群引入了业务配合观察的时间，整体流程也比较长。所以，我们需要寻找更好的解决方案。
既然业务双写集群可以达到要求，基础设施如果代替业务做完这部分岂不是更好？借鉴业务双写集群的思路和云原生的不可变基础设施的理念，我们首先想到的是通过新集群替换老集群而不是原地修改集群；另外，为了在公有云上节省Redis成本，我们积累了kvrocks的实践经验，两者相结合，设计了一种高效的水平扩缩容的方案。
本方案的核心是引入了一个基于kvrocks改造的中间态binlogserver ，它既是一个老集群的Slave节点，又充当了新集群的客户端。一方面，它会从RedisMaster复制全量和增量数据；另一方面，它又充当客户端的角色，将复制来的数据按照新集群的一致性HASH规则写往新的集群。大致的步骤如下，具体的步骤流程可以参考下面的图所示（图5）。
根据当前V1集群的分片启动对应个数binlogserver ，并获取V2集群的一致性HASH规则和group 。每个binlogserver成为V1集群单个分片中Master的Slave ，执行salveof后保存V1中Master传过来的RDB文件并解析，对于每个RDB文件，解析还原成Redis命令，并按CRedis的一致性hash规则写入到V2中，对于后续V1集群传播过来的命令，同样同步到V2中。当这个过程都完成并且binlog追得差不多的时候，为了数据一致性，可以停止V1的写（客户端报错）后由CRedis推送V2的配置或直接推送V2的配置（客户端不报错但数据可能会丢或不一致）， APP端将会顺序切换到V2上来；此过程对用户完全透明，应用端无需做任何操作。

文章图片
图5
通过Redis的水平扩缩容方案，我们解决了之前的几个痛点问题：
持续时间大大缩短，基本上跟V1集群最大实例的大小正相关，因为是并发执行，跟集群分片数无关。根据实际的运维数据来看，集群单个实例为20G ，集群扩缩容在10分钟之内完成，而低于10G的， 5分钟即可完成，大大缩短了扩缩容的周期，并且业务在毫无感知的情况下即可完成扩缩容。由于可以做到秒级切换集群，即使扩缩容后对业务有影响也可以快速回退，因为回退也只是更改了集群的路由指向。扩缩容过程只需要1次切换集群指向， 0次迁移，没有中间态，也无需通过大内存宿主机来实现分拆。对于扩容的集群，很方便再来一次缩容还原回去，缩容同理。对于那些已经水平拆分过的集群，也可以通过这种方式还原回去。既可以扩容也可以缩容，甚至还可以不扩容也不缩容按集群来迁移，比如《携程Cilium+BGP云原生网络实践》一文中提到的云原生网络安全控制试点项目。由于原来Redis集群下面的实例可能同时部署在openstack网络和cilium网络，但云原生安全只能控制cilium网络下的实例，这种情况下就需要迁移Redis实例。如果按之前的运维方式，要按分片来一组组迁移，整个工程可能持续较长时间，并且耗费较多人力，而水平扩缩容可以将一个集群一次性快速迁移到cilium网络，省时省力。扩缩容后无性能损耗。2、运维数据
水平扩缩容方案上线4个月来，已经成功完成了200多次的扩容和缩容。今年某个业务突然请求量暴增十几倍，相关集群经历了多次扩容，每次扩容大多在10分钟内完成，有效地支撑了业务发展。
另一方面，针对申请分片非常多而大但实际使用量非常小的集群，我们也借助水平扩缩容的能力快速地缩小了分片数和申请量。通过这些缩容，有效地提升了整体的资源利用率。
3、一些坑
1）单个key过大导致key被驱逐
在实际水平扩缩容过程中，我们发现有些集群，单个实例中可能会有巨大的key（大于3G），由于V2集群的大小是根据V1大小实时算出来的平均值，一旦V1中某个实例过大，可能会导致写到V2中的某个实例大小大于预期的平均值，从而引起某些key被驱逐。因此，针对这种情况：