一分钱引起的系统设计“踩坑”案例

摘要：阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面很是广，任何一个小故障均可能引起一些社会问题，因此阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在平常的研发运维过程当中，积累了丰富的实战经验。

阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面很是广，任何一个小故障均可能引起一些社会问题，因此阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在平常的研发运维过程当中，积累了丰富的实战经验。今天，阿里妹将为你们分享一个关于故障，排查，分析和改进的真实案例。他山之石能够攻玉，但愿对广大开发和运维工程师带来帮助。

背景说明

某日，作产品X的开发接到客户公司电话，说是对帐出了1分钱的差错，没法处理。本着“客户第一”的宗旨，开发立立刻线查看状况。查完发现，按照产品X当日的年化收益率，正常状况下用户在转入57元后一共收益3分钱，合计是57.03元。可是该客户当日却有一笔消费57.04元，致使客户公司系统对多出的1分钱处理不了。再进一步分析，发现用户收益结转时多了1分钱的收益，而且已消费……

也就是说，原本用户只有3分钱收益，结果多发了1分钱给他，也就给公司形成1分钱的损失！用户在产品X里当天收益本应该是0.03元，怎么会变成0.04元呢？多出的1分钱收益从哪里来的呢？

数据库记录分析

带着上面的一系列疑问，开发人员首先排查了产品X收益的数据库记录。经过查询数据库发现，该用户收益结转在同一天内存在2笔交易记录。交易记录1建立时间为8:00:23，记录2建立时间为8:00:29，交易记录1和2的最后修改时间均为8:00:29，如图4-1所示。

正常状况下产品X收益天天只会结转一次，而这个用户当日有两笔收益结转记录。开发人员怀疑，极可能是出现了并发问题。

继续跟踪第一笔“TXID a”的记录，开发确认线上日志存在超时状况，失败缘由是数据库连接数已满，线程等待提交。

分布式锁超时时间是5s，第一笔记录从建立到修改提交经历了6s，因而可知是在分布式锁失效以后，得到了数据库连接，进行提交成功。

有了以上三个排查思路后，咱们能够开始逆推整个过程。

过程逆推

根据数据库记录逆推当时的运行状况，如图4-2所示。

（1）因为数据库链接数被占满，流水1建立的事务处于等待提交状态。

（2）系统A发现交易失败，重试次数不满8次的，当即发起重试，触发生成流水2的请求。

（3）5s之内数据均被分布式锁拦截，没法提交。

（4）通过5s后，系统B的分布式锁失效，此时事务仍在等待未提交。

（5）6s时，流水2成功越过数据库查询幂等校验发起事务，此时流水1拿到数据库链接，流水1和2两个事务同时提交。

（6）因为数据库未作惟一索引，且支付受理模块打穿下层幂等原则，生成2个TXID，致使两事务同时提交成功。

（7）收益结转重复记帐，用户多了一笔收入。

深刻分析

完成了整个问题的过程逆推后，开发人员进一步分析，发现问题真正的缘由仍是在系统设计上。如图4-3所示，系统A的事务容许必定时间的等待，而上层业务的重试时间又比这个等待的时间要短。这就存在一个问题：系统A的事务还在等待中，业务就又发起了重试。若是是在这个应用场景下（可能业务上对重试要求更高一些），那么对幂等控制的要求就更高了。而仅仅经过一个分布式锁来控制，若是分布式锁的超时时间设置的比事务容许等待的时间短，那么在锁失效以后就必定会同时提交两笔请求。

图4-3 分布式锁超时并发控制时间轴

继续对整个过程抽象化，开发人员得出一个结论：分布式锁在如下条件同时知足的状况下并发控制会被打穿。

（1）上层业务系统层面有重试机制。

（2）业务请求存在必定时间以后提交成功的状况，例如本例中第一次请求在事务等待6s后得到了数据库连接，提交数据库成功。

（3）下游系统缺少其余有效的幂等控制手段。

思考

了解了问题的前因后果后，接下来要怎么解决这类问题呢？咱们想了如下几个方案。

（1）调整B系统上的tr和分布式锁超时时间，tr超时调整为10s，分布式锁超时调整为30s。

（2）防止作收益结转产生并发控制幂等，调整了收益结转流水号的生成规则：前8位取X收益结转传入的交易号的前8位，第10位系统版本设置为“9”，最后8位seq取交易号的最后8位，下降问题出现概率。

方案一：调整超时时间

调整超时时间后，业务重试时间与分布式锁有效时间的分布时间轴如图4-4所示，即在事务容许等待后提交成功的时间以外，再进行重试，另外分布式锁在整个阶段均有效，防止提交。

图4-4 分布式锁超时并发控制时间轴

方案一验证有效。

方案二：增长幂等控制（推荐）

如图4-5所示，单纯靠分布式锁不是控制并发幂等的方式，最稳妥的方式仍是在提交记录的时候经过数据库严格控制幂等。确保不论如何设置超时时间，都不会出现幂等控制的问题。

图4-5 分布式锁超时并发控制时间轴

方案二验证有效。

小结

资金安全无小事，而幂等控制又是资金安全中的重中之重。回顾本文案例，从问题分析定位，到整个逻辑的梳理清洗，其中涉及了三个时间轴的相互做用，再加上事务、分布式锁、重试等，整个问题发生的逻辑仍是比较复杂的。所以，在系统并发幂等控制设计中，单纯的分布式锁并不具有严格控制并发幂等的做用，建议在系统设计时，将第三方惟一性的幂等控制做为幂等控制的兜底方案，控制好这道幂等防线，这样不论业务如何设计，就万变不离其宗了。

做者：阿里云云栖社区 连接：https://www.jianshu.com/p/ae8a69185a5f 來源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。