又一批長事務，P0故障誰來背鍋？

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

最近幾周，發生過多原由爲事務問題引發的服務報錯。現象爲數據庫鏈接池鏈接佔滿，數據庫鏈接長時間等待，最終致使請求線程hang住，服務大面積報錯。這個時候，服務資源、數據庫資源大量空閒，但就是進行不下去，影響是比較惡劣的。

誰來背鍋？固然是架構師。由於此次全部的服務都活着，沒運維什麼事。

面試時，你們可能都會碰到關於事務相關的問題，升級版的多是分佈式事務的問題。在互聯網行業中，一句馬馬虎虎的補償事務就能矇混過關，畢竟都是些短小精悍的接口。

但在不少企業級應用中，這行不通。咱們必須直面慘淡的現實。

爲何要用長事務?

在許多業務很是複雜的後臺系統，常常頻繁操做DB，爲了保證數據的一致性，可以在出錯時回滾數據，一般會使用事務。

就拿最簡單的單機數據庫事務來講。

在事務操做期間，若是持續時間過長，只有等事務結束以後，DB鏈接纔會釋放，此類長時間佔用DB鏈接的事務操做，稱爲長事務。一旦外部有大量請求，併發調用此操做，那麼將會有大量的DB鏈接被持有而沒有被釋放掉，直到鏈接池爆滿。

這個時候，若是有其餘請求到來，那十有八九是以失敗了結。

也就是說，鏈接資源被少數長事務操做佔用。在這種狀況下，即便是最簡單接口查詢，都不可以正常進行。

幾粒老鼠屎，壞了一鍋粥。

一些魔幻的反應

當你去排查這種問題的時候，可能會陷入僵局。jstack顯示，多數請求實際上是阻塞在tomcat的線程池上，並且是一些訪問速度很是快的請求被阻塞。

好比，tomcat的200個線程，有180個阻塞在耗時不到1ms的**/status**接口上。

不少人就一臉懵逼。經驗失靈。

jstack此時的輸出結果，欺騙了咱們。真正形成阻塞的，是那額外的20多個線程。

有哪些改善?

保證事務的短小是一個基本要求，包括但不限於：

應控制慢查詢的調用頻率，儘可能減小慢查詢。不少狀況下，這條規則是自欺欺人的，須要業務作一些妥協。

事務內不該包含任何RPC調用，減小事務的粒度。一般，一些RPC調用，包括其餘非事務資源的調用，耗時很是不可控。若是把它們也歸入事務的範圍以內，勢必會加重資源的佔用。事務內不該包含其餘容易超時或者長時間阻塞的服務，如HTTP調用、IO操做。

次優先級服務如消息隊列，不該該放在事務內，避免由於消息隊列不可用引發的服務不可用。給相似消息隊列的組件，設置一個合理的超時時間的很是有必要的，不然它就會一直等在那裏。但即便是這樣，也儘可能不要把它們歸入到事務操做以內。

跨庫、跨類型（如Redis），不該該放在同一事務中，可避免交叉影響。

你能夠看到上面的這些描述，有些和咱們所追求的數據一致性是相悖的。這不奇怪，依然是CAP原理的權衡。有些業務選擇的是寧肯卡死再也不響應，也不能進入異常數據；有些則首先讓業務運行下去，髒數據會經過補償事務進行修正。

一切看你的選擇。

設計總有人背鍋，補償總有人作出犧牲。

解決方式

那麼如何來快速解決大事務形成的服務不可用問題呢？

除了擴容，實際上是無解。重啓大法也不見得好用。由於被阻斷的請求，會以更兇猛的態勢再次來襲。

你可能會想到調大鏈接池的大小。但在實踐中得知，也很差用，大事務請求會迅速將鏈接池佔滿。

但咱們能夠提早進行防護。

以Spring爲例，事務的使用方式大多數是使用@Transactional註解來控制的，或者是聲明式事務方式。我建議以如下方式進行預防和發現：

1. 從新掃描或者Review業務代碼，排查事務中是否有以上提到的各類狀況。而後將除DB操做外的其餘操做移動到事務以外。

2. 每一個事務操做都給予足夠重視，對於執行復雜度和時間複雜度不肯定的事務，添加超時報警，及時發現引發的緣由。

同時，還須要增強監控，輔助進行問題排查。

1. 業務能夠考慮定時將數據庫鏈接池的信息進行打印，經過看日誌的方式進行初步排查。

2. 使用jstack查詢執行棧，找出阻塞的點。

3. 排查並聯系下游服務，找出主要緣由

xjjdog傾向於使用監控快速發現問題。如圖，經過鏈接池監控，能夠看到數據庫鏈接池鏈接數長時間保持在高位不釋放，同時等待的線程數急劇增長。發生此種現象多數能夠考慮是不是以上緣由引發。

發生問題時，應及時（屢次）使用jstack定位到線程的阻塞位置，而後排查下游服務是否有問題，或者是否存在慢查詢。

最好的狀況是服務已經進行了對代碼的梳理，那麼引發的緣由大機率只剩下了慢查詢。針對慢查詢，druid數據庫鏈接池，提供了sql的聚合，可以查看是每一類查詢語句的具體執行狀況。如圖，短期內SQL請求飆升，最大執行時長上升，鏈接池佔滿：

具體是哪一句SQL所引發的，一目瞭然。

End

長事務問題的危險級別屬於高危型，一般會形成嚴重的後果，能夠經過觀察監控，防範於未然。

最優的解決方式，固然是業務模型的改進。但這東西第一涉及到開發成本，第二涉及到跨部門協做。

出錢的老闆，沒法聽懂你這些夢話。

在一些公司內部，這二者都是讓人抓狂的事情，還不如痛痛快快背個鍋，來得實在。

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​