共计 978 个字符，预计需要花费 3 分钟才能阅读完成。
事件产生在咱们线上的一个遗留问题，问题大抵状况是咱们引入的一个库会导致服务在运行一段时间后呈现死锁，并且会造成整个网站无法访问。
咱们发现通过配置库的一些参数能够防止死锁的状况产生，然而会引发事务无奈回滚的新问题。
因为后者绝对故障等级更低一些，咱们首先进行了故障降级，抉择了优先保障服务运行。
前面则是排查为什么会新的配置会呈现事务无奈回滚，这个事件由我负责排查。
从部门共事那理解了问题的详细情况后我就开始着手进行排查。首先是对问题进行梳理把新引入的库与框架之间的关系以及整体的一个运行流程进行了梳理。
如果要对整个流程做具体的理解，须要浏览的代码量是非常宏大的，不仅须要浏览库，还须要对框架源码进行浏览。
就解决问题而言，我认为须要做粗略的流程梳理即可，通过对整个流程的一个大抵理解，而后确定问题的具体产生地位，而后对具体位置进行具体理解。
在粗略梳理的过程中，我从新引入库开始着手，次要是因为库的代码量绝对较少，浏览起来绝对更快一些，且如果仅从库层面就能解决问题，也能够省略的框架代码的浏览。
对于库源码的理解我通过 wiki + 源码的形式，这样可能更省力的理解库的整个运行机制。
然而理解了库的运行机制后，我发现问题可能呈现在库与框架的配合上。须要波及到框架源码的浏览。
在开始浏览框架源码前，我决定在本地构建一个复现环境，通过对构建出的本地环境对源码进行 debug 调试。
通过重复的 debug 最终终于确定了问题呈现的起因，是因为新库引入后，事务开启时新建一个数据库连贯，而通过 ORM 进行数据库查问时会创立另一个数据库连贯。这就导致事务和 SQL 的执行不是在同一个数据库连贯中，也就造成了数据库事务无奈失效的问题。
确定了问题的起因解决方案就好确定了，咱们只须要保障事务和 SQL 执行在同一个连贯中即可，而解决这个问题只写了三行代码，既保证了性能的残缺，没有侵入库和框架进行底层源码的革新。
这次问题的排查让我想到了福特公司用一万美元画一条线的故事。
画一条线，1 美元；晓得在哪儿画线，9999 美元
这次的问题离不开部门同时的帮忙，在排查的过程中和共事进行了 2-3 轮的沟通。不仅让我对问题有一个全面的意识，也几次在我遇到困惑时，给了我解决问题的灵感，包含在最初解决方案制订后的论证，都蕴含了整个团队的心血。
也心愿这次的一个排查通过可能对看文章的你有一些启发，欢送你分享你的感悟和思考。
