单库平滑迁移至分库分表架构方案

背景

在我们完成新旧系统迁移之后（《系统重构新旧流量平滑迁移方案》），发现随着业务的不断发展，流量愈发的高出预期，原本新架构的单点数据库就有些吃力了。

此时我们需要将新交易平台的单点数据库升级为分库分表架构。

如何将同一个交易系统的数据由单数据库表平滑迁移至分库分表的数据库表中，成了目前主要的问题。

架构图

问题点

1. 关于存量数据和增量数据如何处理
2. 数据完整性如何保证？不能丢数据
3. 数据实时性如何保证？订单临界点？订单的生命周期？（订单初始化 -> 订单交易完成）
4. 数据校验：数据同步之后，是否有问题？新旧数据不一致？
5. 容错保证？灰度？监控？回滚？告警？

方案

读旧写旧、双写读旧、增量数据一致性校验、存量数据同步（DataX）、存量数据一致性校验、双写读新、全量数据一致性校验、旧数据库下线。

数据双写一定要伴随着整个方案的生命周期，考虑到异常可以随时回滚。

读旧写旧

系统原本的方案

双写读旧

此时，我们增加了分库分表，对于我们的应用就有了两个数据源。

针对两个数据源同时进行订单写入操作，但此时我们读的还是旧库。

双写的方案有很多：

1. 基于中间件读binlog日志同步到新库中
2. 代码双写，在基础设施层加一层就可以了，数据量级大，加个MQ，削一下峰。

双写过程中，存在更新操作，我们如何判断是存量数据还是增量数据呢？

可以加一层判断，判断新库里面是否存在数据即可。

增量数据一致性校验

针对已经新库的增量订单，做好数据核对，可以及时发现系统问题。

1. 量级不大，在本地库表写个定时任务写代码（连接双库客户端）比对就可以。
2. 量级大，将双份数据同步到离线数仓，写sql比对也可以
3. 如果考虑到实时性，可以在从库做sql比对
4. 旁路验证策略：在旧系统每个交易节点读取数据的时候，发送一个旁路验证事件，去查一遍新库，做一下数据比对，如果不一样，及时告警，及时处理。

存量数据同步

1. 数据完整性（数据打标）
2. 不能覆盖增量数据（判断新库是否存在）

存量数据一致性校验

1. 量级不大，在本地库表写个定时任务写代码（连接双库客户端）比对就可以。
2. 量级大，将双份数据同步到离线数仓，写sql比对也可以
3. 如果考虑到实时性，可以在从库做sql比对

双写读新

1. 切流要逐步放量，可以根据指定业务字段，做动态配置容器。
2. 读的时候要加开关，增加容错，出现问题，第一时间切回旧库。