問題描述
前端調用我係統的A接口，A接口裏面又去調用了另一個系統的B接口，而B接口回來調用了我係統的C接口。
在我的A和C接口方法上都開啓了事務，並且A和C接口都對同一條記錄做了寫操作，A的寫操作在調用B接口之前。
現象
由於這個問題導致我的接口調用出現了超時，但是實際操作是成功了的。
排查
因爲另外一個系統地同事告訴我，調用C接口超時了，所以我一開始並沒有去看A接口。
C接口實際只有兩個操作：一，到數據庫裏取出這條記錄；二，對記錄進行了回寫。通過查看日誌，發現前面的讀操作很快，只有幾毫秒，但是回寫卻佔用了將近五秒。不相信這麼慢，就去看了下數據庫，只有一百多條記錄，但是問題可以復現的，沒有辦法，我改成了主鍵回寫，但是沒有效果。
之前在主幹和測試並沒有這個問題，所以理所當然，覺得上線可能就不存在了。結果是上了線，還是很慢。咋辦。。。
後來，飛哥幫我線上執行了那條sql，發現很快，只有幾十毫秒。那問題到底在哪裏呢？
這個時候飛哥提出會不會是發生死鎖了，一開始我不太信，但是還是回去檢查了下，仔細一看真的是這個問題，兩個獨立線程的事務，競爭同一條記錄的鎖，可不就死等了嗎？超時，A接口事務結束，C接口事務自然得到執行。
解決
比較糙的法子，我把A接口的事務給去掉了，問題解決
結論
還是要大膽猜想啊，給飛哥點贊。
需要溫習下事務方面的知識啦~