背景
前段時(shí)間沾鳄，因?yàn)轫?xiàng)目需要施流，開始接觸TiDB响疚。TiDB高度兼容MySQL，官方宣稱無需修改任何代碼嫂沉，就可以實(shí)現(xiàn)無縫遷移。今天就分享一個(gè)我們項(xiàng)目中的實(shí)際案例扮碧，然后談?wù)剝烧咧g的一些差異趟章。
先簡單介紹下場景，我們的場景和秒殺場景比較類似慎王，代碼如下（實(shí)際秒殺場景應(yīng)該是庫存校驗(yàn)通過后再創(chuàng)建訂單蚓土，這里只是借此說明decreaseStock()方法會(huì)并發(fā)更新同一行數(shù)據(jù)）：
tx.begin()
err := createOrder()
if err != nil {
tx.rollback()
return
}
// high concurrency
effectRows, err := decreaseStock()
if err != nil || effectRows == 0 {
tx.rollback()
return
}
tx.commit()
乍一看，這段代碼似乎沒什么問題赖淤，事務(wù)異常即回滾蜀漆，全部成功才提交事務(wù)。然而測試過程中卻發(fā)現(xiàn)咱旱，并發(fā)場景下确丢，會(huì)偶現(xiàn)訂單創(chuàng)建成功了，但是庫存并沒有扣減的情況吐限。
場景復(fù)現(xiàn)
為了模擬這種場景鲜侥，我們先創(chuàng)建兩張表，并做初始化：
CREATE TABLE `t` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`a` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
insert into t values (1,10);
CREATE TABLE `t1` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`a` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
開啟兩個(gè)事務(wù)诸典，如下：
| T1 | T2 | |
|---|---|---|
| 1 | begin | begin |
| 2 | insert into t1 values(1, 1); | insert into t1 values(2, 2); |
| 3 | update t set a = a - 6 where id = 1 and a - 6 >= 0; | |
| 4 | update t set a = a - 7 where id = 1 and a - 7 >= 0; | |
| 5 | commit | |
| commit |
在MySQL中描函，我們知道在時(shí)刻4，由于事務(wù)T1還沒有提交狐粱，會(huì)持有id=1這一行的X鎖舀寓，從而導(dǎo)致事務(wù)T2會(huì)阻塞。
但在TiDB中肌蜻，這里就不一樣了互墓，很有可能就會(huì)出現(xiàn)我在之前提到的問題：即事務(wù)T2的insert語句執(zhí)行成功，但更新語句執(zhí)行失敗蒋搜。這是我在本地的測試結(jié)果：
整個(gè)過程事務(wù)沒有任何異常行為轰豆，但如果一不小心這樣的代碼上線了胰伍，嘿嘿，怕是又有程序員要被拿去祭天了酸休。
原因分析
說到這里骂租，就不得不提到TiDB與MySQL的一個(gè)重大不同之處，也就是兩者的事務(wù)模型和隔離級別斑司。
事務(wù)模型
TiDB 使用樂觀事務(wù)模型渗饮，在執(zhí)行
UPDATE、INSERT宿刮、DELETE等語句時(shí)互站，只有在提交過程中才會(huì)檢查寫寫沖突，而不是像 MySQL 一樣使用行鎖來避免寫寫沖突僵缺。類似的胡桃，諸如GET_LOCK()和RELEASE_LOCK()等函數(shù)以及SELECT .. FOR UPDATE之類的語句在 TiDB 和 MySQL 中的執(zhí)行方式并不相同。所以業(yè)務(wù)端在執(zhí)行 SQL 語句后磕潮，需要注意檢查COMMIT的返回值翠胰，即使執(zhí)行時(shí)沒有出錯(cuò)，COMMIT的時(shí)候也可能會(huì)出錯(cuò)自脯。
隔離級別
TiDB 實(shí)現(xiàn)了快照隔離 (Snapshot Isolation) 級別的一致性之景。為與 MySQL 保持一致，又稱其為“可重復(fù)讀”膏潮。
處于可重復(fù)讀隔離級別的事務(wù)不能并發(fā)的更新同一行锻狗，當(dāng)時(shí)事務(wù)提交時(shí)發(fā)現(xiàn)該行在該事務(wù)啟動(dòng)后，已經(jīng)被另一個(gè)已提交的事務(wù)更新過焕参，那么該事務(wù)會(huì)回滾并啟動(dòng)自動(dòng)重試轻纪。
MySQL 可重復(fù)讀隔離級別在更新時(shí)并不檢驗(yàn)當(dāng)前版本是否可見，也就是說叠纷，即使該行在事務(wù)啟動(dòng)后被更新過桐磁，同樣可以繼續(xù)更新。這種情況在 TiDB 會(huì)導(dǎo)致事務(wù)回滾讲岁，導(dǎo)致事務(wù)最終失敗我擂，而 MySQL 是可以更新成功的。MySQL 的可重復(fù)讀隔離級別并非 Snapshot 隔離級別缓艳，MySQL 可重復(fù)讀隔離級別的一致性要弱于 Snapshot 隔離級別校摩，也弱于 TiDB 的可重復(fù)讀隔離級別。
到這里阶淘，我們心里似乎就有那么一點(diǎn)點(diǎn)眉目了衙吩。因?yàn)門iDB并沒有使用類似MySQL那樣的行鎖機(jī)制，而是采用了樂觀事務(wù)模型溪窒，所以在上面的例子中坤塞，事務(wù)T2在時(shí)刻4不會(huì)被阻塞冯勉。而是會(huì)在在事務(wù)提交過程中檢查寫寫沖突，那現(xiàn)在的問題是摹芙，為什么在我們上面的例子中灼狰，事務(wù)T2在提交時(shí)卻沒有檢測到?jīng)_突而提交成功了呢？
而這是因?yàn)槭聞?wù)重試引起的浮禾。
在最新的TiDB3.0版本中交胚，事務(wù)默認(rèn)不會(huì)重試。同時(shí)我們從DBA處了解到盈电，我們的TiDB雖然是3.0版本蝴簇，但卻是從2.1版本升級上來的，為了保持一致性匆帚，事務(wù)重試還是保持了2.1版本的特性熬词，而在2.1版本中，事務(wù)失敗是會(huì)自動(dòng)觸發(fā)重試的吸重。
在我們上面的例子中互拾，事務(wù)T2在提交時(shí)沒有檢測到?jīng)_突正是事務(wù)重試引起的。
查看參數(shù)配置的確如此：
為了進(jìn)一步驗(yàn)證這一猜想晤锹，我們關(guān)閉TiDB的事務(wù)重試機(jī)制
SET @@global.tidb_disable_txn_auto_retry = on;
然后重新執(zhí)行上述例子摩幔，此時(shí)TiDB表現(xiàn)如下：
我們看到彤委，事務(wù)T2在時(shí)刻4依然沒有被阻塞鞭铆，但是提交時(shí)提示寫寫沖突。同時(shí)從最后結(jié)果也可以看到事務(wù)T2完成了回滾焦影。
由于這個(gè)沖突只會(huì)在事務(wù)提交時(shí)才會(huì)提示车遂，所以我們上面的代碼還有一處需要優(yōu)化，就是需要檢查commit的返回值斯辰，commit出錯(cuò)則進(jìn)行事務(wù)回滾舶担，這就是前面提到的TiDB樂觀事務(wù)機(jī)制。
tx.begin()
err := createOrder()
if err != nil {
tx.rollback()
return
}
// high concurrency
effectRows, err := decreaseStock()
if err != nil || effectRows == 0 {
tx.rollback()
return
}
// check commit result
err := tx.commit()
if err != nil {
tx.rollback()
return
}
當(dāng)然彬呻，最后考慮到集群特性一致性衣陶，我們并沒有關(guān)閉事務(wù)重試機(jī)制，而是通過引入分布式鎖來解決了并發(fā)問題闸氮。
其它
MVCC
與MySQL一樣剪况，TiDB也使用MVCC機(jī)制管理版本，但與MySQL不同的是蒲跨，在TiDB中译断，通過設(shè)置一個(gè)會(huì)話級別的系統(tǒng)變量，可以直接讀取歷史數(shù)據(jù)或悲。
set @@tidb_snapshot="2019-08-01 08:00:00";
設(shè)置該變量后孙咪，select語句將可以查詢到該時(shí)間點(diǎn)之前最新版本的變量堪唐，在該時(shí)間點(diǎn)之后更新的變量將不可見。將該變量置空則可以讀取到最新變量翎蹈。
執(zhí)行計(jì)劃
TiDB的執(zhí)行計(jì)劃輸出格式與MySQL有較大差異淮菠，具體個(gè)字段的含義可以參考官方文檔。
總結(jié)
本文主要是通過一個(gè)案例分析了TiDB和MySQL在事務(wù)模型和隔離級別上的一些差異杨蛋。事實(shí)上兜材，雖然協(xié)議兼容，但兩者的區(qū)別遠(yuǎn)不止這一點(diǎn)逞力，在使用TiDB時(shí)還是要更加謹(jǐn)慎曙寡。
