一般数据迁移是通过数据库相关工具进行操作，具体可以参考《21世纪了还愚公移山？数据库这么迁移更快！》。但闲鱼币数据迁移却不同，首先“KingTower”平台的数据结构和“半两”平台的数据结构不同；其次出于对数据安全和稳定性的考虑，两个积分平台只对外提供服务接口，不允许业务方直接操作平台数据库。这就意味着闲鱼币迁移无法利用数据库工具，只能通过两个平台提供的服务接口完成迁移工作。本文将结合闲鱼币迁移过程，提供一种基于服务接口的数据迁移方案，在用户无感知的情况下完成迁移目标。
主动迁移和被动迁移最终目的都是把用户数据从老积分账户数据迁移到新积分上，两种方式各有自己的应用场景，主动迁移主要适用于迁移活跃用户和新增用户，被动迁移主要适用于迁移存量用户。两种迁移遇到的技术难点是一样的。第一并发处理，在上面两种方案只展示了迁移过程中要获取全局分布式锁，对于未迁移的用户在进行加减操作时候同样也要获取全局锁，具体如下图所示，这样才能保证迁移过程中不产生脏数据，本文中的全局锁使用的是Redis实现，这里不再赘述。
第二操作事务性，本文的迁移方案中只有当写入迁移完成标记才算是迁移成功，在这一步前的其他每一步都有可能由于RPC调用产系统异常或超时错误，所以为了保证操作事务性，对于任何一步出错本次迁移都算失败，失败的用户将会进行下面的迁移重试流程。
切换过程采用逐步放量的形式，灰度方式很多我们采用的是先白名单验证，然后用户ID取模1000逐步放量的方式。值得注意的一点是读灰度和灰度要分开进行，当对账没有问题的时候就可以开启读灰度了，在读灰度过程中仍旧保持双写，此时如果读灰度发现问题，仍旧可以回滚会老的服务。但是单写新服务开始后就无法进行回滚，所以在写灰度前需要充分白名单验证。无需关心底层数据存储，只需做好上层业务逻辑兼容即可。
迁移过程可控，通过多维度的迁移监控及早发现问题。
迁移过程受到服务方QPS限制，迁移周期长
迁移过程都是RPC调用，需要处理多种异常情况。
闲鱼技术团队不仅是阿里巴巴集团旗下闲置交易社区的创造者，更是移动与高并发大数据应用新技术的引导者与创新者。我们与Google Flutter/Dart小组密切合作，为社区贡献了多个高star的项目和大量PR。我们正在积极探索深度学习和视觉技术在互动、交易、社区场景的创新应用。闲鱼技术与集团中间件团队共同打造的FaaS平台每天支持数以千万级用户的高并发访问场景。
就是现在！客户端／服务端java／架构／前端／质量工程师面向社会+校园招聘，base杭州阿里巴巴西溪园区，一起做有创想空间的社区产品、做深度顶级的开源项目，一起拓展技术边界成就极致！
*投喂简历给小闲鱼→guicai.gxy@alibaba-inc.com
文章转载自闲鱼技术，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
