开发者社区> 技术小能手> 正文

如何高效排查系统故障?一分钱引发的系统设计“踩坑”案例

简介:
+关注继续查看

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

f0f6a14e82e33ce5c39109f2f78d078dbdb2014d

背景说明

某日,做产品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所示。

9fa78fe15e2d05eb79bfb80d7089391d231864f7

图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)收益结转重复记账,用户多了一笔收入。

d7bc8bdcd5bcabba75f9d90303cea49e20fdc9c9

图4-2 数据库分布式锁超时并发控制失效

深入分析

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

0eec0a757331dae06748f6864dfd452d97c2a98d

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

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

(1)上层业务系统层面有重试机制。

(2)业务请求存在一定时间之后提交成功的情况,例如本例中第一次请求在事务等待6s后获得了数据库链接,提交数据库成功。

(3)下游系统缺乏其他有效的幂等控制手段。

思考

了解了问题的来龙去脉后,接下来要怎么解决这类问题呢?我们想了以下几个方案。

(1)调整B系统上的tr和分布式锁超时时间,tr超时调整为10s,分布式锁超时调整为30s。

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

方案一:调整超时时间

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

9854867052f38fc15d04c1567acc8a8a5d5d9de3

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

方案一验证有效。

方案二:增加幂等控制(推荐)

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

4a31887cb52fdbf5503cbac7d3f2d9715b74da9b

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

方案二验证有效。

小结

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

29c31570afda51b6f8f55cbd10a9c4ead916e314

作者:阿里巴巴集团成长集编委会


本案例选取自《逆流而上:阿里巴巴技术成长之路》。该书通过分享阿里中间件、数据库、云计算、大数据等各个领域发生的典型“踩坑”案例,帮助大家快速提升自我及团队协作,学习到宝贵的处理经验及实践方案,为互联网生产系统的稳定共同努力。有兴趣的童鞋可以在天猫、淘宝搜索、购买此书。


原文发布时间为:2017-11-27

本文作者:逆流而上

本文来自云栖社区合作伙伴“阿里技术”,了解相关信息可以关注“x”微信公众号

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
使用Express3.0实现<Node.js开发指南>中的微博系统
特别说明:本实例仅在windows xp sp3系统下测试通过(其它系统未经过测试)。 这本书,之前有评论过,但之前并不清楚express2.x与3.x会有如此大的差异,导致在写例子的过程中痛苦不已。
847 0
高明!OpenAI提出HER算法,AI系统学会从错误中学习
OpenAI在利用增强学习训练人工智能系统任务上不断地取得进步。他们发布的新平台显示,可以允许人工智能系统从错误中吸取教训,并将错误视为系统的目标而非失败。
4062 0
Windows系统案例排查实战(一)- 域用户登录后立即注销
在接下来的这个系列中我们会以实例来说明Windows系统案例一般如何进行排查,包括一些常见工具的使用以及排查问题的思路。 这次我们遇到的一个有意思的的问题是这样的:用户在云上自建了Windows活动目录(AD),包括一台域控和几台域成员,当用户采用本地账户登录域成员时没有问题,但是当用户使用域账号登录时,登录进行到最后一步显示桌面时,突然自动注销了。
3266 0
linux系统cpu占用过高故障排查
首先使用top命令查看cpu使用情况
65 0
基于PAI 10分钟搭建一个简单推荐系统
阿里巴巴技术专家傲海为大家带来基于PAI10分钟搭建一个简单推荐系统的介绍。内容包括个性化推荐业务流程,协同过滤算法,推荐方案的架构,以及实际操作四个部分。
2590 0
+关注
技术小能手
云栖运营小编~
7208
文章
9
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载