最近幾周，發生過多起因爲事務問題引起的服務報錯。現象爲數據庫連接池連接佔滿，數據庫連接長時間等待，最終導致請求線程hang住，服務大面積報錯。這個時候，服務資源、數據庫資源大量空閒，但就是進行不下去，影響是比較惡劣的。
誰來背鍋？當然是架構師。因爲這次所有的服務都活着，沒運維什麼事。
面試時，大家可能都會碰到關於事務相關的問題，升級版的可能是分佈式事務的問題。在互聯網行業中，一句馬馬虎虎的補償事務就能矇混過關，畢竟都是些短小精悍的接口。
但在很多企業級應用中，這行不通。我們必須直面慘淡的現實。
爲什麼要用長事務?
在許多業務非常複雜的後臺系統，經常頻繁操作DB，爲了保證數據的一致性，能夠在出錯時回滾數據，通常會使用事務。
就拿最簡單的單機數據庫事務來說。
在事務操作期間，如果持續時間過長，只有等事務結束之後，DB連接纔會釋放，此類長時間佔用DB連接的事務操作，稱爲長事務。一旦外部有大量請求，併發調用此操作，那麼將會有大量的DB連接被持有而沒有被釋放掉，直到連接池爆滿。
這個時候，如果有其他請求到來，那十有八九是以失敗告終。
也就是說，連接資源被少數長事務操作佔用。在這種情況下，即使是最簡單接口查詢，都不能夠正常進行。
幾粒老鼠屎，壞了一鍋粥。
一些魔幻的反應
當你去排查這種問題的時候，可能會陷入僵局。jstack顯示，多數請求其實是阻塞在tomcat的線程池上，而且是一些訪問速度非常快的請求被阻塞。
比如，tomcat的200個線程，有180個阻塞在耗時不到1ms的/status接口上。
很多人就一臉懵逼。經驗失靈。
jstack此時的輸出結果，欺騙了我們。真正造成阻塞的，是那額外的20多個線程。
有哪些改善?
保證事務的短小是一個基本要求，包括但不限於：
應控制慢查詢的調用頻率，儘量減少慢查詢。很多情況下，這條規則是自欺欺人的，需要業務做一些妥協。
事務內不應包含任何RPC調用，減少事務的粒度。通常，一些RPC調用，包括其他非事務資源的調用，耗時非常不可控。如果把它們也納入事務的範圍之內，勢必會加劇資源的佔用。事務內不應包含其他容易超時或者長時間阻塞的服務，如HTTP調用、IO操作。
次優先級服務如消息隊列，不應該放在事務內，避免因爲消息隊列不可用引起的服務不可用。給類似消息隊列的組件，設置一個合理的超時時間的非常有必要的，否則它就會一直等在那裏。但即使是這樣，也儘量不要把它們納入到事務操作之內。
跨庫、跨類型（如Redis），不應該放在同一事務中，可避免交叉影響。
你可以看到上面的這些描述，有些和我們所追求的數據一致性是相悖的。這不奇怪，依然是CAP原理的權衡。有些業務選擇的是寧可卡死不再響應，也不能進入異常數據；有些則首先讓業務運行下去，髒數據會通過補償事務進行修正。
一切看你的選擇。
設計總有人背鍋，補償總有人做出犧牲。
解決方式
那麼如何來快速解決大事務造成的服務不可用問題呢？
除了擴容，其實是無解。重啓大法也不見得好用。因爲被阻斷的請求，會以更兇猛的態勢再次來襲。
你可能會想到調大連接池的大小。但在實踐中得知，也不好用，大事務請求會迅速將連接池佔滿。
但我們可以提前進行防禦。
以Spring爲例，事務的使用方式大多數是使用@Transactional註解來控制的，或者是聲明式事務方式。我建議以以下方式進行預防和發現：
重新掃描或者Review業務代碼，排查事務中是否有以上提到的各種情況。然後將除DB操作外的其他操作移動到事務之外。
每個事務操作都給予足夠重視，對於執行複雜度和時間複雜度不確定的事務，添加超時報警，及時發現引起的原因。
同時，還需要加強監控，輔助進行問題排查。
業務可以考慮定時將數據庫連接池的信息進行打印，通過看日誌的方式進行初步排查。
使用jstack查詢執行棧，找出阻塞的點。
排查並聯系下游服務，找出主要原因
xjjdog傾向於使用監控快速發現問題。如圖，通過連接池監控，可以看到數據庫連接池連接數長時間保持在高位不釋放，同時等待的線程數急劇增加。發生此種現象多數可以考慮是否是以上原因引起。
又一批長事務，P0故障誰來背鍋？
發生問題時，應及時（多次）使用jstack定位到線程的阻塞位置，然後排查下游服務是否有問題，或者是否存在慢查詢。
最好的情況是服務已經進行了對代碼的梳理，那麼引起的原因大概率只剩下了慢查詢。針對慢查詢，druid數據庫連接池，提供了sql的聚合，能夠查看是每一類查詢語句的具體執行情況。如圖，短時間內SQL請求飆升，最大執行時長上升，連接池佔滿：
又一批長事務，P0故障誰來背鍋？
具體是哪一句SQL所引起的，一目瞭然。
End
長事務問題的危險級別屬於高危型，通常會造成嚴重的後果，可以通過觀察監控，防範於未然。
最優的解決方式，當然是業務模型的改進。但這東西第一涉及到開發成本，第二涉及到跨部門協作。
出錢的老闆，無法聽懂你這些夢話。
在一些公司內部，這兩者都是讓人抓狂的事情，還不如痛痛快快背個鍋，來得實在。