如何不停机完成单表拆分

在业务发展的早期，为了快速迭代及时响应市场需求，通常架构比较简单，比如数据库表，开始是单表，但随着业务的发展，数据量逐步膨胀，开始考虑分库分表。

本文以交易系统的订单表为例：

订单通常分为两张表：

• 订单主表（order_main）

• 订单明细表（order_entry）

注意点：

• 订单主表与明细表一对多关系
• 每时每刻都有新的数据进来，可能是新增订单，也可能是订单修改，业务方不接受停机迁移方案

问题：

• 老order_main的订单id采用mysql自增方式，如果采用分表比如1024张，关于订单id肯定要提供单独的id生成器服务
• 迁移到新表，采用新的订单id，老的订单id与新的订单id需要建立映射关系

核心步骤

一、双写

原来的创建订单接口上，增加新库的写入逻辑

过程：

• 老库创建订单
• 申请新的订单号（为了查库方便，新订单分表键采用订单号，订单号采用id序列号+buyer_userId后6位组成，理论上可最多分100W张表）
  • 这样分的好处，无论是按买家维度查订单列表，还是按订单号查询，都能快速定位到具体表
• 在新库创建订单
• 并建立新老order_id之间的映射关系

新订单，如果是修改操作，新、老表都同时修改，保证事务。

老订单，修改操作，只操作老表

二、全量数据迁移

• 启动任务，开始全量迁移老表的数据，到新的表中，返回新的order_id
• 并建立新老order_id之间的映射关系

注：

• 老的订单要在老库完结。此时对老库表记录修改时，需要发kakfa，异步任务监听，同步数据到新表

三、读切到新库

• 所有依赖于老的订单表的接口，增加中间层逻辑
• 先根据老的订单号查新的订单号
• 将流量切到新的订单服务接口

注意：

• 上面的步聚2和3之间会有时间间隔，所以这段时间的订单修改记录要单独存储
• 在步骤3完成后，对这些增量数据再做一次同步

四、下双写

• 对老订单表的写依赖下线