【GBA】2013年度-1688额度中心并发交易场景下锁机制问题

本文通过一个具体案例分析了在1688极速到账等场景中因数据加锁不合理导致的并发问题及解决方案。指出在事务处理过程中,若数据源在锁定前被其他交易更改,将引发数据不一致问题。提出了在锁定数据前增加额度查询步骤并确保失败时能回滚的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

BUG作者:四摧

BUG标题:

事务处理过程中数据加锁不合理,导致同一数据源在交易过程中被其他交易改变

BUG影响:

1688极速到账、账期支付等场景下并发下单失败或金额占用不准确现象,造成担保方金额亏损

BUG发现过程:
1)前期参与开发代码review,梳理1688极速到账、账期支付等场景事务处理过程和锁使用机制,识别代码风险点;
2)测试设计阶段:针对性地设计各种交易复杂场景高并发压测;
3)测试过程中:编写数据校验脚本,在上亿条日志中检查每笔交易订单正确性,并找到必现条件;

原因为:交易过程中要用到的数据源被其他买家与该卖家交易时改变,导致失败却没有进行回滚,必现条件如下图所示:

BUG解决方法:

在数据源被锁住的代码里再次添加查询剩余额度代码后再进行金额占用,并保证失败后能进行数据回滚(注:第一次查询剩余额度目的是查询需要用到几种授信源和各自的剩余金额进行数据锁定,开发认为在查询和数据锁定之间时间极短不可能发生改变,故在锁内未加入再次查询节省性能开销),同时在回归过程中评估修改影响,注意锁内操作变多带来的接口性能下降问题,经测试确实下降3MS左右幸好满足预期。
GBA传承
1、针对数据库锁测试时,一定要考虑并发测试场景,并确保查询和使用数据源都在锁内进行,避免数据不准确;

2、性能压测过程中除了观察接口调用返回正确性,还需要观察产生的数据是否完全和预期相符,数据量大时建议用脚本或者编写小工具进行校验,在上亿条日志中不要放过任何一条可疑日志。

个人感受:
1、事务处理和数据锁相关测试,需要介入代码review,并理清各种约束条件和触发场景设计压测用例;
2、需求评估阶段单纯的认为接口压测仅需要把各种接口串联在一起进行并发测试,只需要观察接口返回正确性就OK,差点疏忽了复杂场景下接口返回是成功了但数据可能不一致的场景;
3、涉及金额的测试,出现概率就算再小也是大事,需要多留一份心。

 

 

转自:http://www.taobaotest.com/blogs/2528

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值