線上併發事務死鎖問題排查

x1aoda1 發表於 2021-07-23

併發事務死鎖問題排查

業務系統上線後,服務日誌報錯:

Jul 20 15:10:30 xxx: {"level":"error","error":"Error 1213: Deadlock found when trying to get lock; try restarting transaction","time":"2021-07-20T15:10:35.845197649+08:00","message":"error delete entities before insert"}

上游業務系統監聽多個topic,但不同topic有交集,交集為共同更新我們系統的某一張表。服務雖然一直在報錯,但是資料並沒有出現重複及丟失的情況。針對這個問題現象進行排查。

1 排查思路:

1.1 首先調研下mysql InnoDB鎖的詳細說明:

概念:

共享鎖(S Lock):允許事務讀一行資料,多個事務可以併發對某一行資料加S Lock

排他鎖(X Lock): 允許事務刪除或更新一行資料,只有行資料沒有任何鎖才可以獲取X Lock

共享鎖和排他鎖,就是我們日常見到的讀鎖和寫鎖。一個執行緒加了讀鎖,其他執行緒如果是讀取資料,也可以加讀鎖繼續讀取。而一旦有一個執行緒需要加寫鎖,前提是該資料沒有加鎖,如果當前資料已經加了讀鎖或者寫鎖,當前執行緒必須等到鎖釋放,才可以加寫鎖。

共享鎖和排他鎖,在InnoDB中對應的是行級別鎖。但是InnoDB除了支援共享鎖(S Lock)和排他鎖(X Lock),還支援表級別的兩把鎖,意向共享鎖(IS Lock)和意向排他鎖(IX Lock),意向共享鎖和意向排他鎖雖然是表級別的鎖實際應用在行級鎖之中,用來鎖定一個小範圍。IS Lock事務想要獲得一張表中某幾行的共享鎖; IX Lock事務想要獲得一張表中某幾行的排他鎖

  • 行鎖 :鎖定一行資料,即我們常見的共享鎖和排查鎖
  • 間隙鎖:鎖定一個範圍,但不包含記錄本身。例如資料庫中id為3,8,11,那麼鎖定的區間可能為(-∞, 3), (3, 8), (8, 11), (11, +∞)。假如插入的資料id為6,那麼此時鎖定的區間為(3, 6), (6, 8)被鎖定,不包括要插入的6
  • 行鎖 + 間隙鎖:鎖定一個範圍,包括記錄本身。例如資料庫中id為3,8,11,那麼鎖定的區間可能為(-∞, 3], (3, 8], (8, 11], (11, +∞]。那麼假如插入id為6的資料,此時鎖定的區間為(3, 6], (6, 8]兩個部分,可以看到,6也被鎖定了。

1.2 間隙鎖有什麼用?

我們瞭解了MySQL的InnoDB的常見鎖,瞭解了表級別間隙鎖會應用在行級別的範圍之中。那麼間隙鎖有什麼好處。

我們應該聽說過幻讀,即在同一事務下,連續執行兩次同樣的SQL語句可能導致不同的結果,第二次的SQL語句可能返回之前不存在的行。InnoDB使用行鎖 + 間隙鎖的方式解決這個問題。當然,InnoDB儲存引擎在查詢資料時是不存在鎖的,這是因為查詢的資料來自於快照版本,即歷史資料。

1.3 MySQL常見操作對鎖的應用

  • Insert操作:資料庫插入一行資料時,需要獲取行鎖
  • Update操作:更新一條記錄時,如果記錄存在,需要行鎖,如果不存在,需要行鎖+間隙鎖。
  • Delete操作:刪除一條記錄時,如果記錄存在,需要行鎖;如果記錄不存在,行鎖+間隙鎖。
  • Select操作:不會加鎖,因為查詢的資料主要來自於快照版本,即歷史資料。除非顯示的呼叫lock share mode或for update。
-- 顯示的為查詢新增共享鎖S Lock
select * from a where id = 1 lock in share mode ;
-- 顯示的為查詢新增排他鎖X Lock
select * from a where id = 1 for update ;

1.4 服務為啥會Deadlock

通過前期對Mysql InnoDB鎖相關資料的瞭解,分析我們系統為啥會出現大量的deadlock日誌報錯。

Jul 20 15:10:30 xxx: {"level":"error","error":"Error 1213: Deadlock found when trying to get lock; try restarting transaction","time":"2021-07-20T15:10:35.845197649+08:00","message":"error delete entities before insert"}

deadlock原因

造成死鎖競爭狀態後,mysql會將優先的事務提交,另一個事務釋放鎖,然後丟擲報錯資訊。

2 解決思路

併發情況下減少delete-insert事務操作

可以迴避這種在事務中,delete-insert多執行緒操作的問題,例如我們可以先查資料是否存在,不存在不執行delete操作,避免不存在執行delete操作,觸發mysql的行鎖+間隙鎖機制。如果存在我們delete,只會用到mysql的行鎖。這就一定程度上避免了鎖競爭無法釋放的問題。但是這樣操作也會存在一定的風險,是否可以軟刪除,避免高併發情況下,出現資料已經被刪除,而其他事物正在刪除不存在的資料問題。

單程式下可考慮在事務上加鎖

sessionA和sessionB兩個事務,在競爭的情況下,刪除了不存在的記錄,會觸發mysql的行鎖+間隙鎖。主要出發點在於,與其在mysql競爭間隙鎖的過程中報錯,然後事務回滾,資源大量浪費,不如在進入事務之前進行併發控制。雖然鎖的粒度有點粗,但是相對於事務一直回滾,服務端不停列印錯誤日誌,是更能接受的。

多程式高可用的情況

對於高可用多程式情況,可以通過分散式鎖結局。如果不想借助非mysql的外部鎖結局,那麼也可以考慮對delete-insert事務進行排序,加入有序佇列中,挨個消化。這實質上也是變相做了同步操作。

思考方向:儘可能避免觸發mysql的間隙鎖。

3 最終解決辦法

單程式加了一個鎖,對多執行緒的delete-insert事務,同步處理。

// 對執行緒併發呼叫的方法
func (ei entitiesImpl) UpsertEntitis(ctx context.Context, id string, entities model.Entities) error {
	conn, err := DB.Conn(ctx)
	if err != nil {
		return err
	}
	defer conn.Close()
	// 對delete-insert做同步處理
	entityMux.Lock()
	defer entityMux.Unlock()
	tx, err := conn.BeginTx(ctx, &sql.TxOptions{})
	if err != nil {
		return nil
	}
	res, err := tx.ExecContext(ctx, "delete from entities  where id = ?", id)
	if err != nil {
		tx.Rollback()
		return err
	}
	_, _ = res.RowsAffected()
	for _, v := range entities {
		_, err := tx.ExecContext(ctx, "INSERT INTO entities (`id`) VALUES (?)",v.id)
		if err != nil {
			tx.Rollback()
			return err
		}
	}
	tx.Commit()
	huskar.Debug(ctx).Int("entities_size", len(entities)).Msg("insert new entities")
	return nil
}

相關文章