- 本文节选自即将出版的《可伸缩服务架构：框架与中间件》一书，作者：李艳鹏、杨彪、李海亮、贾博岩、刘淏。
- 点击文末原文链接可以直达《可伸缩服务架构：框架与中间件》书籍主页。
处理分布式缓存迁移是比较困难的，通常我们将其分为平滑迁移和停机迁移。这里讲解通用的迁移方案，扩容实际上是迁移的一种特殊案例，我们在下面学习的方案全部适用。我们会在讲解该方案的过程中，以扩容为例来说明相应的步骤和实现细节。
１．平滑迁移
平滑迁移适合对可用性要求较高的场景，例如，线上的交易服务对缓存依赖较大，不能忍受停机带来的业务损失，也没有交易的低峰期，我们对此只能采用平滑迁移的方式。
平滑迁移使用的是双写方案，方案分成4个步骤：双写、迁移历史数据、切读、下双写。
这种方式还有一个变种，就是不需要迁移老数据，在第1步中双写后，在一定的时间里通过新规则对新缓存进行写入，新缓存已经有了足够的数据，这样我们就不用再迁移旧数据，直接进入第3步即可。
首先，假设我们的应用现在使用了具有两个分片的缓存集群，通过关键字哈希的方式进行路由，如图4-19所示。
图4-19
因为两个分片已经不能满足缓存容量的需求，所以现在需要扩容到4个分片，达到原来两倍的缓存总大小，因此我们需要迁移。
迁移的具体过程如下。
第1步，双写。按照新规则和旧规则同时往新缓存和旧缓存中写数据，如图4-20所示。
图4-20
这里，我们仍然按照旧的规则，也就是关键字哈希除以2取余来路由分片，同时按照新的规则，也就是关键字哈希除以4取余来路由到新的4个分片上，来完成数据的双写。
这个步骤有优化的空间，因为是在成倍扩容的场景下，所以我们不需要准备4个全新的分片。新规则中前两个分片的数据，其实是旧规则中两个分片数据的子集，并且规则一致，所以我们可以重用前两个分片，也就是说一共需要两个新的分片，用来处理关键字哈希取余后为2和3的情况；使用旧的缓存分片来处理关键字哈希取余后0和1的情况即可。如图4-21所示。
图4-21
第2步，迁移历史数据。把旧缓存集群中的历史数据读取出来，按照新的规则写到新的缓存集群中，如图4-22所示。
图4-22
在这个过程中，我们需要迁移历史数据，在迁移的过程中可能需要迁移工具，这也需要一部分开发工作量。在迁移后，我们还需要对迁移的数据进行验证，表明我们的数据迁移成功。
在某些应用场景下，缓存数据并不是应用强依赖的，在缓存里获取不到数据，可以回源到数据库获取，因此在这种场景下通过容量评估，数据库可以承受回源导致的压力增加，就可以避免迁移旧数据。在另一种场景下，缓存数据一般是具有时效性的，应用在双写期间不断向新的集群中写入新数据，历史数据会逐渐过时，并被从旧的集群中删除，在一定的时间流逝后，在新的集群中自然就有了最新的数据，也就不再需要迁移历史数据了，但是这需要进行评估和验证。
第3步，切读。把应用层所有的读操作路由到新的缓存集群上，如图4-23所示。
图4-23
这一步把应用中读取的操作的缓存数据源转换成新的缓存集群，这时应用的读写操作已经完全发生在新的数据库集群上了。这一步一般不需要上线代码，我们会在一开始上双写时就实现开关逻辑，这里只需要将读的开关切换到新的集群即可。
第4步，下线双写。把写入旧的集群的逻辑下线，如图4-24所示。
图4-24
这一步通常是在双写和切读后验证没有任何问题，并保证数据一致性的情况下，才把这部分代码下线的。同时可以把旧的分片下线，如果是扩容的场景，并且重用了旧的分片1和分片2，则还可以清理分片1和分片2中的冗余数据。
２．停机迁移
停机迁移的方法比较简单，通常分为停止应用、迁移历史数据、更改应用的数据源、启动应用这4个步骤，如图4-25所示。
图4-25
具体的迁移步骤如下：
停机应用，先将应用停止服务。
迁移历史数据，按照新的规则把历史数据迁移到新的缓存集群中。
更改应用的数据源配置，指向新的缓存集群。
重新启动应用。
这种方式的好处是实现比较简单、高效，能够有效避免数据的不一致，但是需要由业务方评估影响，一般在晚上交易量比较小或者非核心服务的场景下比较适用。
3.一致性哈希
实际上，Redis的客户端Jedis本身实现了基于一致性哈希的客户端路由框架，这种框架的好处是便于动态扩容，当一致性哈希中的节点的负载较高时，我们可以动态地插入更多的节点，来减少已存节点的压力。
一致性哈希算法是在1997年由麻省理工学院的Karger等人在解决分布式缓存问题时提出的一种方案，设计目标是解决网络中的热点问题，后来在分布式系统中也得到了广泛应用。研究过Redis和Memcache缓存的人一般都了解一致性哈希算法，他们都在客户端实现了一致性哈希。
一致性哈希的逻辑如图4-26所示：
图4-26
在收到访问一个主键的请求后，可通过下面的流程寻找这个主键的存储节点。
求出Redis服务器（节点）的哈希值，并将其配置到0-232的圆 （continuum）上。
采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
从数据映射到的位置开始顺时针查找，找到的第1台服务器就是将数据保 存的位置。
如果在寻找的过程中超过232仍然找不到节点，就会保存到第1台服务器 上。
在扩容的场景下添加一台服务器节点5时，只有在圆上增加服务器的位置到逆时针方向的第一台服务器上的键会受到影响，如图4-27所示。
图4-27
我们看到，在节点3和节点4之间增加了节点5，影响范围是节点3到节点5之间的数据，而并不影响其他节点的数据，因此，这为缓存的扩容提供了便利性，当缓存压力增加且缓存容量不够时，我们通常可以通过在线增加节点的方式来完成扩容。
END
✎推荐阅读
【推荐书籍】
