Codis介绍

Codis 是一种Redis集群的实现方案，与Redis社区的Redis cluster类似，基于slot的分片机制构建一个更大的Redis节点集群，对于连接到codis的Redis客户端来说, 除了部分不支持的命令外，与连接开源的 Redis Server 没有明显的区别, 客户端代码基本需要进行修改，Codis-proxy会根据访问的key进行slot的计算，然后转发请求到对应的Redis-server，对于客户端来说，中间的codis-proxy是不可见的，因此根据客户业务的需要，可以使用codis构建大规模的Redis 服务，或者仅仅是用于把请求分担多个Redis-server提高系统的吞吐量。

与业界著名的twproxy相比，除了支持Redis的转发，coids还支持不停机的数据迁移，使用户可以在容量或者吞吐量要求有变化时，轻松进行节点的增减，本文主要对codis的迁移原理进行分析，并提出一个可行的优化点。

本文是基于codis3.0版本。

Codis迁移实现原理

Codis-dashboard在启动时，运行了4个后台线程(goroutine)，包括后台redis状态同步、proxy状态同步、slot事件处理、sync事件处理，并提供了slot相关的RestFUL API进行slot与Redis-group归属关系的定义、迁移的定义和触发。

如下结构定义一个slot与Redis-group的归属关系和迁移关系，GroupId表示索引为Id的slot所属的redis-group，而Action用于表示一次迁移，Action.TargetId表示该slot要迁移的目标redis-group的Id，Action.State表示迁移的状态，主要有Pending、Preparing、Prepared、Migrating、Finished几种状态。

type SlotMapping struct {
                Id      int `json:"id"`
                GroupId int `json:"group_id"`
                
                Action struct {
                                Index    int    `json:"index,omitempty"`
                                State    string `json:"state,omitempty"`
                                TargetId int    `json:"target_id,omitempty"`
        UpdatedAt int64 `json:"updated_at,omitempty"`
                } `json:"action"`
}

手动进行一次迁移过程，可以用如下命令来触发：

codis-admin --dashboard=ADDR -slot-action --create --sid=ID --gid=ID，比如把slot 10迁移到group 5，则可以执行” codis-admin --dashboard=ADDR -slot-action --create --sid=10 --gid=5”

如果是把多个slot迁移到同一个server，则可以使用如下命令，一次性来定义若干个迁移操作，codis-admin --slot-action --create-range --beg=ID --end=ID --gid=ID，比如把slot 10~15迁移到group 5，则可以执行” codis-admin --dashboard=ADDR -slot-action –create–range --beg=10 –end=15 --gid=5”。

一次迁移的执行过程中，slot的Action的状态会发生变化，过程为：

也可以触发codis进行rebalance，命令为：codis-admin --dashboard=ADDR –rebalance --confirm，codis会自动把slot往一些新加入的节点进行迁移，使各个节点负责的slot均衡。

Codis迁移的测试

经测试，对于一个64G规模的集群（由8个节点组成，每个节点8G），使用redis-benchmark写满数据，每个key的value长度为32字节，总共写入341446298（3.4亿）条数据，扩容到128G，即对其中的512个slot进行迁移。

测试结果如下：

1 第一个slot，从06:49:31开始到07:47:23结束，从总耗时3472 seconds，也即57分52秒

2 后续的7个slot，分别花费时间为3463、3468、3472、3468、3472、3474、3470 seconds，基本在57~58分之间，由于耗时非常长，没有记录后续的时间数据

从测试结果来看，迁移速度非常慢，每迁移一个slot需要花费基本1个小时，因此使用codis时，需要监控数据量，当数据不够时，需要进行及时的扩容，否则当空间不够时的故障处理和恢复时间可能影响线上业务。

Codis迁移代码分析及瓶颈分析

从测试结果来看，迁移速度确实非常慢，极端情况下可能会影响线上业务，因此对迁移过程进行分析和优化就很有必要，下边对关键的实现代码handleSlotRebalance 、StartDaemonRoutines、ProcessSlotAction进行解读，并分析优化改进的地方。

01 handleSlotRebalance实现分析

这个函数的主要逻辑分为三部分：

1）找到需要迁移的slot；

2）为每个新节点分配slot；

3）生成迁移操作；

上面的代码的逻辑是：

1）根据节点个数和slot槽数(固定的1024)，计算每个节点上应该负责的slot槽数，表示为bound；

2）对每个redis-group，找到需要迁移出去的slot，表示为pending；

生成迁移计划：

1）遍历所有的redis-group，对于已有的slot小于应该负责的slot槽数的，就要迁移一些槽进来；

2）所有的redis-group，决定需要迁移进来的slot列表，表示为plans；

遍历迁移计划，使用create actionRange生成一系列的slot action，并保存到etcd，下一步就需要由后台线程去etcd中取出slot操作进行分别处理。

02 StartDaemonRoutines

这个代码是在dashboard启动时就启动的后台任务，每隔5秒钟触发一次slot操作，且只会运行一个slot操作任务。

03 ProcessSlotAction实现分析

分为两步Topom.SlotActionPrepare和Topom.processSlotAction。

从上面代码可以看出：

1 从0开始从所有的slot中，选择一个Action.State不为ActionNothing的slot进行处理，比如，如果为迁移某个slot，那么该slot的Action.State就为ActionPending，就可以被处理到

2 如果是多个slot需要处理，那么是从最小的slot开始，一个一个接一个的顺序处理，直到没有需要处理的slot，然后继续每过10秒就处理一遍

下边再分析processSlotAction的实现：

可以看出：

1 循环调用底层的redisp.MigrateSlot函数，从源slot向目的slot做一次迁移操作

2 每次调用redis的slotsmgrttagslot命令进行一次迁移，只迁移一个key；迁移完成后暂停一个时间，再继续进行后续迁移操作；应该是为了避免大量的迁移操作，影响了业务对redis的读写

3 直到迁移返回个位为0，即表明迁移完成

04 瓶颈分析

从上面的分析可以得出：

1 多个slot的迁移，是一个一个slot串行处理的

2 对一个slot的迁移，是逐个key进行串行处理的，每迁移一次需要从codis-dashboard向redis-server发一次迁移命令，每发出一个迁移命令只迁移一个key

这个设计的好处是，迁移过程对客户业务的影响很小，但是也有一些明显的缺点：

1 迁移效率较低，如果数据量很大，那么迁移时间会很长

2 如果扩容较晚，有些节点已经较为满了，那么很可能因为迁移较慢而还没有处理到这些slot，从而导致对这些节点的写入失败

由于扩容一般会有一定的提前量，且会选在业务低峰期进行，因此可以对该迁移方案进行优化，可以在不对业务访问造成太大的影响的前提下提高迁移效率。

Codis代码优化

根据上面对迁移实现的分析，优化的思路为：

1 对多个slot进行迁移，尽量进行并行化处理

2 调用redis-server进行迁移时，可以一次迁移多个key

01 Slot迁移并行化

从代码实现的分析，有2个点可以选择：

1 Topom.ProcessSlotAction中，封装SlotActionPrepare和processSlotAction，然后启动多个线程(goroutine)，实现多个slot并行操作

2 Topom.StartDaemonRoutines中，修改ProcessSlotAction的调用，启动多个线程(goroutine)

最终处理代码简单化的考虑，选择了方案2，同时考虑到如下几点：

1 节点资源的限制，为避免耗费太多资源，限制最多10个线程并发

2 由于一般多个slot会映射到同一个redis-server，而这样的多个slot进行并行化处理不会有提升效果，反而会影响到客户业务的访问，因此在并行时选择slot时，要选择不在同一个redis-server的slot，使迁移真正的并行化

如下优化代码，启动至多10个线程进行slot事件的处理。

同时修改SlotActionPrepare，选择一个状态为Pending且没有归属于同一个redis-server的slot，进行处理。

02 Multikey迁移

修改redis-server的迁移指令，支持一次迁移多个key，为了灵活性，把迁移的个数从外部传入，代码比较显而易见，参考如下：

Codis迁移优化测试结果

经过验证，对于一个64G规模的集群，使用redis-benchmark写满数据，每个key的value长度为32字节，总共写入341446298（3.4亿）条数据，扩容到128G，即对其中的512个slot进行迁移。最终测试结果为：

1 从10:05:41开始，到10:34:50结束，最终花费时间为29分钟

2 每个slot的迁移时间平均为25秒。比如slot-64，从10:05:41，到10:06:07，花费26秒；slot-195,从10:05:42，到10:06:08，花费26秒，slot-576,从10:05:48，到10:06:13，花费25秒

因此，经过优化后迁移性能有极大的提升。当然当前的配置也是考虑到了尽量不影响客户的业务访问，一次迁移的数据量并不是最大化的，在某些情况下，可以修改配置，一次迁移更多的key，可以更加快速的完成迁移。

本文转载自公众号中间件小哥（ID：huawei_kevin）。

原文链接：

https://mp.weixin.qq.com/s/kfHx8GKN0ZHYXO456boCnQ

创作场景

Redis 实践系列丨 Codis 数据迁移原理与优化