记录些系统设计架构实现方案（2）

100亿级分库分表，不停机迁移，如何处理？

分库分表&数据迁移的技术重要性

分库分表&数据迁移，不仅仅是一个技术难题，考验的一个人的技术功底。分库分表&数据迁移，也是一个协调难题，需要协调开发、运维，而是一个人就能搞定的。考验的一个人的协调功底。

积分系统的巨大价值

伟大的系统，都是迭代出来的。在早期，为了快速试错，菜鸟积分系统单体系统，数据库是单库多表。随着业务快速增长，菜鸟C端用户已经过3亿+，消费者从查、取、寄快件开始慢慢扩展到玩、购。

玩、购主要是裹酱商城以及各个业务线多种多样的活动，这些活动包含了停留、任务、开奖、分享、签到、助力、兑换、抽奖等多种多样的互动手段。菜鸟的积分代表用户虚拟权益，在其中起到了钩子的作用。菜鸟的积分为互动产品本身提供了某些“价值”，使得消费者在平台停留时间增加。

从这个维度来说，菜鸟积分系统一直扮演着一个底层核心角色，承载用户核心资产。

积分系统的功能架构如下

总体的 功能架构，如上图所示。

积分系统面临的巨大挑战

在大促期间需要支持大流量的活动，整个积分系统在大促期间面临挑战是非常大的。

菜鸟C端用户已经过3亿+，单体应用不可能支撑，存储层的单库多表也是不可能支撑的。

为了支持菜鸟C端营销业务的持续爆炸式增长，菜鸟积分系统需要升级。

问题是：如何在业务不暂停的情况下，完成积分从单库单表到分库分表的数据架构升级？

还有就是：这一高风险操作是如何逐步分阶段完成的？

在开始设计迁移方案之前，菜鸟积分团队认真进行了问题分析，发现了本项目面临以下几个主要的挑战：

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

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

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

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

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

• 可监控、可灰度、可回滚：阿里稳定性三板斧：可监控、可灰度、可回滚。如果要求可灰度、可回滚，则必须要求数据的双向同步，加大了数据同步链路的风险。

1. 可灰度:任何变更,都必须是可以灰度的,即控制变更的生效范围.先做小范围变更,验证通过之后才扩大范围

2. 可监控:在灰度的过程中,必须能做到可监控,能了解到变更之后对系统的应用

3. 可回滚:当通过监控发现变更后会引发问题时,还需要有方法可以回滚

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

重构风险极大，但不得不做

由于涉及到数据的重构，项目风险极大，没处理好可能就要背包走人了。

• 第一：数据一旦错乱或者丢失，有可能会造成部分数据不可恢复。

• 第二：或者即使能恢复，恢复时间通常也很长，按小时，甚至按天计算。业务很难承受这个代价。

然而，既然风险这么大，那能不干这个分库分表迁移项目吗？不能。

• 因为菜鸟积分系统在2020年双十一期压测期间，已经成为瓶颈了。

• 已经到了不得不迁移重构的地步，而且这个重构越晚做，风险越大。

正所谓：箭在弦上，不得不发。

100亿级库表重构和迁移的方案设计

存量数据分析

表的情况：积分系统主要2张核心的表，积分总表和积分明细表。

数据的情况：2个库中的数据达百亿，积分明细的增量数据规模大，日新增数据也在千万级。

服务接口分析

积分系统对外提供的服务接口主要有：

• 读积分

• 加积分

• 扣减(冻结积分)

• 退还积分。

为了临时解决大促期间系统性能瓶颈问题，读积分会通过缓存tair（类似redis）做查询，击穿缓存才会到达数据库，写积分会直接更新数据库(缓存是)。数据库的压力，在写不在读。通过观察，大促期间，数据库瓶颈是在写积分对数据库的压力上。如果把数据库纵向扩展，升级最高配置，也不能彻底解决问题：

• 一方面预算上花费太高，

• 另一方面也不一定能支撑预估流量，即使这次侥幸度过，将来也无法再做水平扩展。

解决100亿级库表性能瓶颈的可选方案

解决100亿级库表性能瓶颈的可选方案，主要有三个方案：

1. 分库分表，数据迁移：考虑数