以下文章来源于阿里开发者，作者星花

一  前言

拆库&数据迁移说白了，考验的不是一个人的技术功底，而是一个人干活的细致程度，以及抗压能力。无论在哪个公司，数据库迁移的机会都不会太多，因此，我也是非常珍惜这次历练，用阿里的一句老话来说就是 “因人成事，借事修人”。写这篇文章的目的主要是自己进行一个总结，也希望能给需要的同学们一些参考。

二  背景

在星爷的《大话西游》中有一句非常出名的台词：“曾经有一份真挚的感情摆在我的面前我没有珍惜，等我失去的时候才追悔莫及，人间最痛苦的事莫过于此，如果上天能给我一次再来一次的机会，我会对哪个女孩说三个字：我爱你，如果非要在这份爱上加一个期限，我希望是一万年！”在我们开发人员的眼中，这个感情就和我们数据库中的数据一样，我们多希望他一万年都不改变，但是往往事与愿违，随着公司的不断发展，业务的不断变更，我们对数据的要求也在不断的变化。在早期为了快速尝试新业务，菜鸟积分系统在发展初期是单体系统，数据库是单库多表。随着菜鸟C端业务快速增长，服务消费者已经过3亿+，对于消费者阵地也从查、取、寄开始慢慢扩展到玩、购。主要是裹酱商城以及各个业务线多种多样的活动，这些活动包含了停留、任务、开奖、分享、签到、助力、兑换、抽奖等多种多样的互动手段。权益在其中起到了钩子的作用，引导流量进入互动业务，互动产品本身提供了某些“价值”，使得消费者在平台停留时间增加，“价值”承载的实体之一就是虚拟权益积分。菜鸟积分系统一直扮演着一个底层核心角色，承载用户核心资产。在大促期间需要支持大流量的活动，因此整个积分系统在大促期间面临挑战是非常大的。

为了支持菜鸟C端营销业务的持续爆炸式增长，我们启动了菜鸟积分系统升级工作，如何在业务不暂停的情况下，完成积分从单库单表到分库分表的数据架构升级，背后实施步骤以及遇到过哪些意想不到的坑，本文将分享这一高风险操作是如何逐步分阶段完成的。

三  面临挑战

在开始设计迁移方案之前，我们首先需要调研系统现状，通过调研系统现状之后，我们发现了本项目面临以下几个主要的挑战：

• 从1到N在系统架构上差异较大：原来的是单库单表的系统，之前的设计开发都是基于单库单表的，例如SQL查询，在单表上建了多个索引来支持这些查询业务，切换到分库分表之后，不带分表键的查询就不能支持了。

• 业务不可暂停：整个迁移过程，营销业务不允许暂停，类似于开着飞机换引擎，比一些银行系统的暂停服务来做迁移的难度大。

• 数据量大：单表数据量超级大，对数据同步链路的稳定性提出了很大的挑战。

• 系统架构旧：积分系统建立时间很早，所选用的技术框架老旧，有些甚至已经不再维护了，导致整个改造成本加大，改动过程风险很大。

• 接口版本多：由于历史原因，积分的发放和消耗接口版本非常多，有些历史包袱在里面，使得迁移的难度和风险都很大。

• 可监控、可灰度、可回滚：为了降低整个项目的风险，按照阿里稳定性三板斧，要求整个迁移过程可监控、可灰度、可回滚。这三个要求对服务重构没有大问题，但是对于这个同时涉及数据迁移的项目，难度反而是加大了，如果不要求可灰度、可回滚，只用做数据的从老的单库单表到新的分库分表的单向迁移就可以了，而如果要求可灰度、可回滚，则必须要求数据的双向同步，加大了数据同步链路的风险。

• 时间紧迫：需要在特定时间前完成拆库和数据源迁移(近1个多月的时间)，封网期间加大了操作流程的复杂性。

备注：涉及到数据的重构项目风险极大，没处理好可能就要背包走人了，如果数据一旦错乱或者丢失，有可能会造成部分数据不可恢复，或者即使能恢复（不同于单纯的服务重构），恢复时间通常也很长，按小时，甚至按天计算。业务很难承受这个代价。在期间师兄送了我四字方针：胆大心细。既然风险这么大，那我们能不干这个分库分表迁移项目吗？不能！因为菜鸟积分系统在2020年双十一期压测期间，已经成为瓶颈了，已经到了不得不迁移重构的地步，而且这个重构越晚做风险越大。这个时候就适合阿里的一条价值观上场了：“If not now, when? If not me, who?” So, let's do it.