码迷,mamicode.com
                                                                              首页 > 其他好文 > 详细

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

                                                                              时间:2019-05-09 13:53:42      阅读:37      评论:0      收藏:0      [点我收藏+]

                                                                              标签:nbsp   开机   有关   mic   img   支付宝   time   队列   emoji   

                                                                              故障描述

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

                                                                              技术?#35745;? src=

                                                                              图一

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

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

                                                                               

                                                                              故障原因分析

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

                                                                              技术?#35745;? src=

                                                                              图二

                                                                               

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

                                                                              技术?#35745;? src=

                                                                              ?#26082;?/p>

                                                                               

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

                                                                              方法有两种:

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

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

                                                                               

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

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

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

                                                                              DBA回复如下:

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

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

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

                                                                               

                                                                              故障根本原因

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

                                                                              技术?#35745;? src=

                                                                              图四

                                                                               

                                                                              到这里,其实故障原因已经很清楚了,我们在代码层面也确实查到了问题。因为DBA提供的sql中,连insert sql的主机名也列了出来,并且现场没有被破坏,我们使用jstack应该还能找到正在?#21364;?#30340;线程才对;于是在?#22791;?#25925;障2天后,我们又?#36855;?#32500;把那台机器的jvm stack给打印了一下,果然发现?#21364;?#30340;线程仍然存在技术?#35745;? src=

                                                                              堆栈如下:

                                                                              技术?#35745;? src=

                                                                              图五

                                                                               

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

                                                                               

                                                                              解决方法

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

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

                                                                               

                                                                               

                                                                              知识点

                                                                              1、事务,spring AOP

                                                                              2、httpclient,超时设置

                                                                               

                                                                                  求关注

                                                                              技术?#35745;? src=

                                                                               

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

                                                                              标签:nbsp   开机   有关   mic   img   支付宝   time   队列   emoji   

                                                                              原文地址:https://www.cnblogs.com/donlianli/p/10837869.html

                                                                              (0)
                                                                              (0)
                                                                                 
                                                                              举报
                                                                              评论 一句话评论(0
                                                                              0条  
                                                                              登录后才能评论!
                                                                              ? 2014 mamicode.com 版权所有 京ICP备13008772号-2
                                                                              迷上了代码!
                                                                              宁夏11选5开奖查询