转载自 如何高效排查系统故障？一分钱引发的系统设计“踩坑”案例
背景说明
某日，做产品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所示。
图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-2 数据库分布式锁超时并发控制失效
深入分析
完成了整个问题的过程逆推后，开发人员进一步分析，发现问题真正的原因还是在系统设计上。如图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 分布式锁超时并发控制时间轴
方案二验证有效。
小结
资金安全无小事，而幂等控制又是资金安全中的重中之重。回顾本文案例，从问题分析定位，到整个逻辑的梳理清洗，其中涉及了三个时间轴的相互作用，再加上事务、分布式锁、重试等，整个问题发生的逻辑还是比较复杂的。因此，在系统并发幂等控制设计中，单纯的分布式锁并不具备严格控制并发幂等的作用，建议在系统设计时，将第三方唯一性的幂等控制作为幂等控制的兜底方案，控制好这道幂等防线，这样不论业务如何设计，就万变不离其宗了。
