记录一次余额迁移的坑(测试角度)
一、这是一个迁移流程图;现在把action做个简单的记录:备注:本次迁移核心是迁移流水,通过流水的收入-支出-余额=0,在平台用户最少的时候进行迁移(凌晨2点进行);找出收入和支出有差异的--仔细对账查账;然后运维配合,流水扎帐,记录最大的流水id;继续账单平账,然后进行快照流水回放迁移,迁移完成后,进行对账,收入-支出-余额=0那就很好,恭喜你没有采坑,系统健壮;我们就不是,然后就一点一点查账对账;账单平了以后,可以继续迁移,迁移增量(首先我们是热牵),迁移增量可能 要进行好几次,每次迁移都要对账;
No.
|
ACTION
|
REMARK
|
执行任务
|
---|---|---|---|
1 | 针对user_balance表执行一次获取差异账单(账单一) | 查出账单,通常是54笔 |
select u.code, u.nickname , u.available_balance, ( |
2 | 取一次流水表最大id | 取出流水表中的最大的id(MAX_ID) | SELECT MAX(id) from user_balance ; |
3 | 再获取一次获取差异账单(账单二) | 查出账单,通常是54笔 | select u.code, u.nickname , u.available_balance, ( (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =1) - (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =2) ) as '收入减支出' from user u where available_balance <> ( (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =1) - (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =2) ); |
4 | 验证账单一和账单二是否一致 | ||
5 | 进行差异账单平账 | 差异账单进行调整,通过资金后台功能,导入excel,自动进行平账 |
需要提供导入平账的能力; fund-manager已提供http接口 |
核对差异账单正确性 |
SELECT * FROM user_account WHERE 1 limit 100; SELECT * FROM org_account where 1 limit 100; |
||
6 | 进行快照流水迁移 |
从0开始迁移到MAX_ID为止到流水,进行业务回放 |
需要提供从0到N流水号回放的能力 fund-manager已提供http接口 |
7 | 迁移完成后进行资金系统对账 | 收入-支出 -余额 = 0 |
select u.account_id, u.account_name, u.user_code, ( |
8 | 检验是否有差异 | 正常情况下应该是0 | |
9 | 进行差异数据单笔重试 |
需要提供单笔业务重试的能力 fund-manager已提供http接口 |
|
10 | 对资金系统进行备份 | sg_account库 | |
11 | 增量迁移 |
提供增量迁移能力,记录老系统ID和新系统ID,在执行业务之前,需要进行幂等(执行转账业务之前,fund-manager), user_balance存在order_no为 |
需要提供从X到Y流水号回放的能力(和从0到MAX_ID的能力是同一个) fund-manager已提供http接口 |
12 | 应用发布(含业务回归验证) |
应用发布 |
|
13 | 再次进行增量迁移 | 提供增量迁移能力(可执行之前一样的操作) |
需要提供从X到Y流水号回放的能力(和从0到MAX_ID的能力是同一个) fund-manager已提供http接口 |
14 | 迁移完成后进行资金系统对账 | 收入-支出 -余额 = 0 |
select u.account_id, u.account_name, u.user_code, ( |
15 | 进行系统间对账 |
系统内对账: 资金系统快照2 - 资金系统快照1 = 增量流水轧差 + 新业务流水 系统间对账:老系统增量流水和新系统迁移流水进行对账 |
增量流水获取 |
16 | 针对差异数据进行单笔调账 |
需要提供单笔业务重试的能力 fund-manager已提供http接口 |
二、开发踩得的坑,测试流的泪
1. userbalance表, serialNo/orderNo 重复, 与迁移程序唯一单号生成策略冲突,导致部分数据丢失。
eg: 接口并发,同一笔订单可能生成多笔,我就看到一个用相同订单号有17笔;
2. userbalance有记录,但user表没有用户 引发bug、账不平。
eg:用户userCode被修改,或者直接被删除,但是有消费过,balance里面没有被处理
3. account-business 对于已存在的commonbill账单,再次申请会进行数据覆盖,导致后面重复的单号数据会覆盖前面转账成功的数据,从而account-business与account-core账对不上。
4. account-business调用转账时,金额小于等于0会直接变成成功,不走account-core。 应改为金额等于0直接成功,不走core。金额小于0报错
三、测试需要关注点:
- 测试用例质量和checklist是否清晰明了:第一次接触余额迁移,我知道必须重视,可是我还是重视不够,写出的checklist没有进行评审,就上手了
- 迁移风险,迁移方案没有完全吃透:如果迁移失败,有回滚方案吗?迁移的性能瓶颈?有些历史数据处理--待入账?接入新数据兼容问题等,上线后,全面业务回归