记一次自动恢复的支付故障

释放双眼,带上耳机,听听看~!

故障描述

作为一个老牌OTA公司,公司早些年订单主要来源是PC网站和呼叫中心。我在入职公司大约半年后,遇到一次非常诡异的故障。有一天早上,大概也是这个季节,阳光明媚,程序猿刚起床,洗洗涮涮,准备去迎接初恋般的工作日,却突然收到一大堆报警,线上消息队列大量积压;当然,我还是一如既往的非常勤奋地在9点之前就到公司的;但是作为一名新员工,环视四周,组内其他员工都还没到公司,运维也都在路上,故障就这样突然降临了。我赶紧开机登录堡垒机,连接线上机器,tail 错误日志。但是线上10几个系统,我看了好几个系统,都没有发现有什么错误,这就尴尬了。但是统计消息队列,超过好几千的消息待消费。我当时就在想,这些消息都是什么鬼。截图如下:

记一次自动恢复的支付故障

图一

看到这里,你一定会问数量为604和881个的消息是做什么?知道这些消息的逻辑不就解决问题了么?话说当时我也是这么想的,可是当时我作为一名新人,才开始接触业务不到3个月,还完全没有这么深的业务积累(这个时候知道业务是多么重要)。

既然系统看不到任何错误,我也没有什么办法了,当时因为刚入职没多久,还有点寄希望于领导来解决。转眼间半个小时已经过去,故障仍然没有恢复,从业务反馈来看,微信支付宝等支付方式不受影响。受影响的只是信用卡支付(其实当时信用卡量占比挺高)和分销支付(后来了解到,其实这两种模式都是信用卡支付模式)。领导还在堵车,运维也只是到了几个小兵,我找运维把几个机器的stack打印了一下,也没有发现什么问题;运维也陆续到岗,运维准备出大招,重启系统。但是就在此时,突然系统自动恢复了。所有积压的消息自动被消费,信用卡支付也可以了。好,系统竟然有自我修复功能,佩服;

 

故障原因分析

后来,经过一番努力,还是找到一点蛛丝马迹,我发现系统的一个消费消息的定时任务,在故障期间一直在报错,因为是高可用的job机制,4台机器,只有抢占到锁的服务器才能获取到访问数据库消息权利,所以报错信息比较分散,4台机器都有。

记一次自动恢复的支付故障

图二

 

可以判定,这个sql一直异常导致job根本无法获取到消息,而另外的生产者又不断的往队列放消息,进而导致消息积压。两个系统关系如下:

记一次自动恢复的支付故障

图三

 

虽然故障总结了,但是我们心里也不踏实,如何找到系统故障的根本原因,以防止以后再次出现这种故障呢?

方法有两种:

1、去查代码,所有跟这个表相关的sql,都需要仔细review一下,但是你也不一定能查到原因,因为这个场景肯定是不好复现的,要不然早就发现这个问题了。

2、借助外力,从DB层面查导致这个sql无法执行成功的原因;

 

方法1看似简单,其实非常不可行。首先,虽然跟这个表相关的sql,只有几十个,但是都是正常的sql,没有使用for update锁死表的sql。也没有存在未关闭的事务,因为事务是通过AOP配置的;

所以只能寄希望于方法2了,让DBA去查;

好歹我们的DBA足够给力,只用了1天多的时间就查出来了。

DBA回复如下:

1、有事务没有及时提交,且连接也没有关闭,导致该事务一直处于开启状态并持有锁,后续update操作是全表扫描,因此会有锁等待。

2、最后该连接后续一直没有操作,达到空闲超时3600秒(我们的故障时间正好也是1小时)后被mysql server断开,锁才被释放。(mysql设置:wait_timeout = 3600)

最牛B的是DBA贴出了没有提交事务的SQL;sql我就不贴出来了,我们根据DBA提供的线索,找到了代码的问题;

 

故障根本原因

后来我们查看代码,如上面DBA所说,消息没有被消费处理,是因为有一个mysql客户端,即我们的支付应用程序,在进行快捷支付的时候,向队列插入一条记录,然后在事务中向第三方发起了调用。使用的是httpclient工具发起的调用,但是设置超时时,只设置了连接超时时间(connectionTimeout)为30秒,没有设置响应超时时间(soTimeout),这样当出现网络问题时,程序就会一直等第三方响应,然后事务也一直没有提交。而在job程序中,需要将这个queue的所有记录给更新,但是又取不到表锁(见图三),就不断的报lock wait timeout的错误;其实对使用spring AOP框架的研发,很容易犯这种错误。我们从 https://tech.meituan.com/2018/04/19/trade-high-availability-in-action.html 这篇总结里面的1.5段也能看出,美团支付也在这块也栽过坑;

记一次自动恢复的支付故障

图四

 

到这里,其实故障原因已经很清楚了,我们在代码层面也确实查到了问题。因为DBA提供的sql中,连insert sql的主机名也列了出来,并且现场没有被破坏,我们使用jstack应该还能找到正在等待的线程才对;于是在时隔故障2天后,我们又让运维把那台机器的jvm stack给打印了一下,果然发现等待的线程仍然存在记一次自动恢复的支付故障

堆栈如下:

记一次自动恢复的支付故障

图五

 

与之对应的代码,我就不贴了;

 

解决方法

1、临时解决方法,将响应超时时间设置上,但这无法根除问题,只是降低再次出现问题的概率;

2、长久解决方案,修改框架,使用编程式事务,将所有远程调用从事务中剥离出来。

 

 

知识点

1、事务,spring AOP

2、httpclient,超时设置

 

    求关注

记一次自动恢复的支付故障

 

给TA打赏
共{{data.count}}人
人已打赏
随笔日记

SpringBoot第二篇:配置文件详解一

2020-11-9 4:47:48

随笔日记

五分钟搞定 HTTPS 配置,二哥手把手教

2020-11-9 4:47:50

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索