天天看點

又一批長事務,P0故障誰來背鍋?

最近幾周,發生過多起因為事務問題引起的服務報錯。現象為資料庫連接配接池連接配接占滿,資料庫連接配接長時間等待,最終導緻請求線程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傾向于使用監控快速發現問題。如圖,通過連接配接池監控,可以看到資料庫連接配接池連接配接數長時間保持在高位不釋放,同時等待的線程數急劇增加。發生此種現象多數可以考慮是否是以上原因引起。

又一批長事務,P0故障誰來背鍋?

發生問題時,應及時(多次)使用jstack定位到線程的阻塞位置,然後排查下遊服務是否有問題,或者是否存在慢查詢。

最好的情況是服務已經進行了對代碼的梳理,那麼引起的原因大機率隻剩下了慢查詢。針對慢查詢,druid資料庫連接配接池,提供了sql的聚合,能夠檢視是每一類查詢語句的具體執行情況。如圖,短時間内SQL請求飙升,最大執行時長上升,連接配接池占滿:

又一批長事務,P0故障誰來背鍋?

具體是哪一句SQL所引起的,一目了然。

End

長事務問題的危險級别屬于高危型,通常會造成嚴重的後果,可以通過觀察監控,防範于未然。

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

出錢的老闆,無法聽懂你這些夢話。

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