1、拆库
拆库优势: 很方便实现线性扩展
原始订单库: order(数据量1.4亿)
新库: 按照user_id 维度hash user_id % 512 的规则 新增512个库 order_0 ~ order_511
写入规则:
新老都可以写、新系统按订单生成规则生成 64位id、老系统写入规则保持不变
读取规则:
新老系统都可以读、短id指定读order库(老库)、长id读 order_0 ~ order_511
2、唯一id生成器规则:
40位时间差 + 9位库号 + 6位应用号 + 9位顺序号
最大QPS: 512 * 1000 = 50万
最大应用数: 81个
使用寿命:可以使用30年
3、灰度:
按流量灰度:
按照 0.1% -> 1% -> 20% -> 50% -> 100% 依次递增、采用nginx+lua 开发灰度方案 (建议)
逐步平滑迁移到新系统
4、数据同步方案:
#### 新-> 老:
方案A:
1、采用mysql 7+(mariaDB 10.1 +)多住一从特性、往老表同步
方案B:
2、采用canal解析binlog 同步到老库
#### 老->新
无需同步、短id直接读老order库
5、 此方案需要解决以下几个问题(前置条件):
1: 老库订单表 主键自增去掉、业务逻辑层实现自增
2: 老系统查询 不能关联查询 、子查询 等操作
3: 老系统订单所有Integer类型 需要改成Long型
6、 此方案优势:
1:不需要历史数据迁移、只需新系统往老系统汇总数据
2: 平滑迁移
7、 后续改进:
1: 汇总数据迁移到检索系统(ES)
8、存在的问题:
1、历史表数据量依然巨大、查询慢问题没有解决、可以推出一部分历史数据
