还好DBA给力 记一次自动恢复的支付故障根本解法_sql

一、故障描述

作为一个老牌OTA公司，公司早些年订单主要来源是PC网站和呼叫中心。我在入职公司大约半年后，遇到一次非常诡异的故障。

有一天早上，大概也是这个季节，阳光明媚，程式猿刚起床，洗洗涮涮，准备去迎接初恋般的工作日，却突然收到一大堆报警，线上讯息伫列大量积压。

当然，我还是一如既往的非常勤奋地在9点之前就到公司的；但是作为一名新员工，环视四周，组内其他员工都还没到公司，运维也都在路上，故障就这样突然降临了。

我赶紧开机登入堡垒机，连线线上机器，tail 错误日志。但是线上10几个系统，我看了好几个系统，都没有发现有什么错误，这就尴尬了。

统计讯息伫列，超过好几千的讯息待消费。我当时就在想，这些讯息都是什么鬼。截图如下：

看到这里，你一定会问数量为604和881个的讯息是做什么？知道这些讯息的逻辑不就解决问题了么？

话说当时我也是这么想的，可是当时我作为一名新人，才开始接触业务不到3个月，还完全没有这么深的业务积累（这个时候知道业务是多么重要）。

既然系统看不到任何错误，我也没有什么办法了，当时因为刚入职没多久，还有点寄希望于领导来解决。

转眼间半个小时已经过去，故障仍然没有恢复，从业务反馈来看，微信支付宝等支付方式不受影响。

受影响的只是信用卡支付（其实当时信用卡量占比挺高）和分销支付（后来了解到，其实这两种模式都是信用卡支付模式）。

领导还在堵车，运维也只是到了几个小兵，我找运维把几个机器的stack打印了一下，也没有发现什么问题；运维也陆续到岗，运维准备出大招，重启系统。

但是就在此时，突然系统自动恢复了。所有积压的讯息自动被消费，信用卡支付也可以了。

好，系统竟然有自我修复功能，佩服！

二、故障原因分析

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

可以判定，这个sql一直异常导致job根本无法获取到讯息，而另外的生产者又不断的往伫列放讯息，进而导致讯息积压。

两个系统关系如下：

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

方法有两种：

方法1看似简单，其实非常不可行。

首先，虽然跟这个表相关的sql，只有几十个，但是都是正常的sql，没有使用for update锁死表的sql。也没有存在未关闭的事务，因为事务是通过AOP配置的。

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

好歹我们的DBA足够给力，只用了1天多的时间就查出来了。DBA回复如下：

最牛的是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

到这里，其实故障原因已经很清楚了，我们在程式码层面也确实查到了问题。

因为DBA提供的SQL中，连insert sql的主机名也列了出来，并且现场没有被破坏，我们使用jstack应该还能找到正在等待的执行绪才对。

于是在时隔故障2天后，我们又让运维把那台机器的jvm stack给打印了一下，果然发现等待的执行绪仍然存在。

堆叠如下：

与之对应的程式码，我就不贴了。

解决方法：

知识点

作者：猿界汪汪队

来源：https://www.cnblogs.com/donlianli/p/10837869.html

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]