數(shù)據(jù)庫(kù)事務(wù)是訪問(wèn)可能操作各種數(shù)據(jù)項(xiàng)的一個(gè)數(shù)據(jù)庫(kù)操作序列，這些操作要么全部成功，要么全部失敗。提起事務(wù)，大家都知道ACID屬性，這些特性在前邊的文章里都有詳細(xì)的講解，感興趣的可以通過(guò)歷史文章查看。
在Java中有并發(fā)編程，可以多線程并發(fā)執(zhí)行，并發(fā)可以提高程序執(zhí)行的效率，也會(huì)帶來(lái)線程安全的。數(shù)據(jù)庫(kù)事務(wù)和多線程一樣，為了提高數(shù)據(jù)庫(kù)處理事務(wù)的吞吐量，數(shù)據(jù)庫(kù)也支持并發(fā)事務(wù)，在并發(fā)處理數(shù)據(jù)的過(guò)程中，也存在著安全問(wèn)題。
我們本文將從并發(fā)事務(wù)可能引發(fā)的問(wèn)題、解決并發(fā)問(wèn)題、MySQL的鎖機(jī)制、鎖的實(shí)現(xiàn)等方面逐漸深入，探討高并發(fā)場(chǎng)景下的事務(wù)調(diào)優(yōu)問(wèn)題。
并發(fā)事務(wù)可能引發(fā)的問(wèn)題
1.數(shù)據(jù)丟失
2.臟讀、
3.幻讀
4.不可重復(fù)讀
事務(wù)隔離解決的并發(fā)問(wèn)題
? 數(shù)據(jù)丟失可以基于數(shù)據(jù)庫(kù)中的悲觀鎖來(lái)避免發(fā)生，即在查詢時(shí)通過(guò)在事務(wù)中使用 select xx for update 語(yǔ)句來(lái)實(shí)現(xiàn)一個(gè)排他鎖，保證在該事務(wù)結(jié)束之前其他事務(wù)無(wú)法更新該數(shù)據(jù)。
? 我們也可以基于樂(lè)觀鎖來(lái)避免，即將某一字段作為版本號(hào)，如果更新時(shí)的版本號(hào)跟之前的版本一致，則更新，否則更新失敗。剩下3 個(gè)問(wèn)題，其實(shí)是數(shù)據(jù)庫(kù)讀一致性造成的，需要數(shù)據(jù)庫(kù)提供一定的事務(wù)隔離機(jī)制來(lái)解決。
MySQL 的鎖機(jī)制
InnoDB實(shí)現(xiàn)了兩種類型的鎖機(jī)制：共享鎖（S）和排他鎖（X）。共享鎖允許一個(gè)事務(wù)讀數(shù)據(jù)，不允許修改數(shù)據(jù)，如果其他事務(wù)要再對(duì)該行加鎖，只能加共享鎖；排他鎖是修改數(shù)據(jù)時(shí)加的鎖，可以讀取和修改數(shù)據(jù)，一旦一個(gè)事務(wù)對(duì)該行數(shù)據(jù)加鎖，其他事務(wù)將不能再對(duì)該數(shù)據(jù)加任務(wù)鎖。
不同的鎖機(jī)制會(huì)產(chǎn)生不同的事務(wù)隔離級(jí)別，不同的隔離級(jí)別分別可以解決并發(fā)事務(wù)產(chǎn)生的問(wèn)題，如讀未提交、讀已提交、可重復(fù)讀、可序列化等。（1號(hào)發(fā)的《MySQL的事務(wù)隔離級(jí)別和長(zhǎng)事務(wù)，看這一篇就夠了》一文中有介紹過(guò)）
InnoDB中的讀已提交和可重復(fù)讀隔離事務(wù)是基于多版本并發(fā)控制（MVCC）實(shí)現(xiàn)高性能事務(wù)。一旦數(shù)據(jù)被加上排他鎖，其他的事務(wù)將無(wú)法加入共享鎖，且處于阻塞等待狀態(tài)，如果一張表有大量的請(qǐng)求，這樣的性能將是無(wú)法支持的。
MVCC對(duì)普通的Select 不加鎖，如果讀取的數(shù)據(jù)正在執(zhí)行delete或者update操作，這時(shí)讀取操作不會(huì)等待排他鎖的釋放，而是直接利用MVCC讀取該行的數(shù)據(jù)快照。MVCC避免了對(duì)數(shù)據(jù)重復(fù)加鎖的過(guò)程，大大提高了毒草在的性能。（數(shù)據(jù)快照是指在該行的之前版本的數(shù)據(jù)，而數(shù)據(jù)快照的版本是基于undo實(shí)現(xiàn)的，undo是用來(lái)做事務(wù)回滾的，記錄了回滾的不同版本的行記錄）
鎖的具體實(shí)現(xiàn)算法
InnoDB既實(shí)現(xiàn)了行鎖，也實(shí)現(xiàn)了表鎖，行鎖是通過(guò)索引實(shí)現(xiàn)的，如果不通過(guò)索引條件檢索數(shù)據(jù)，那么InnoDB將表中所有的記錄進(jìn)行加鎖，其實(shí)就是升級(jí)為表鎖。
行鎖的具體實(shí)現(xiàn)算法有三種：record lock、gap lock和next-key lock。record lock是專門對(duì)索引項(xiàng)加鎖；gap lock是對(duì)索引項(xiàng)之間的間隙加鎖，next-key lock則是前面兩種的組合，對(duì)索引項(xiàng)及其之間的間隙加鎖。
只在可重復(fù)讀或以上隔離級(jí)別下的特定操作才會(huì)取得 gap lock 或 next-key lock，在 Select 、Update 和 Delete 時(shí)，除了基于唯一索引的查詢之外，其他索引查詢時(shí)都會(huì)獲取 gap lock 或 next-key lock，即鎖住其掃描的范圍。
優(yōu)化高并發(fā)事務(wù)
上邊的講解，都是為了對(duì)事務(wù)、鎖和隔離級(jí)別更加深入了解，下邊將聊聊高并發(fā)場(chǎng)景下的事務(wù)是如何調(diào)優(yōu)的。
- 結(jié)合業(yè)務(wù)場(chǎng)景，使用低級(jí)別事務(wù)隔離
在高并發(fā)業(yè)務(wù)中，為了保證業(yè)務(wù)數(shù)據(jù)的一致性，操作數(shù)據(jù)庫(kù)時(shí)往往會(huì)使用不同級(jí)別的事務(wù)隔離，隔離等級(jí)越高，并發(fā)性能就越低。
那在實(shí)際的業(yè)務(wù)中，我們要如何選擇呢，下邊舉兩個(gè)例子：
在修改用戶的最后登錄時(shí)間，或者用戶的個(gè)人資料等數(shù)據(jù)時(shí)，這些數(shù)據(jù)都只有用戶自己登錄和登陸后才會(huì)修改，不存在一個(gè)事務(wù)提交的信息被覆蓋的可能，所以這樣的業(yè)務(wù)我們就最低的隔離級(jí)別。
如果賬戶的余額或者積分的消費(fèi)，就可能存在多個(gè)客戶端同事消費(fèi)一個(gè)賬戶的情況，此時(shí)我們應(yīng)該選擇可重復(fù)讀隔離級(jí)別，來(lái)保證當(dāng)一個(gè)客戶端在操作的時(shí)候，其他客戶端不能對(duì)該數(shù)據(jù)進(jìn)行操作。
- 避免行鎖升級(jí)表鎖
我們知道，InnoDB中行鎖是通過(guò)索引實(shí)現(xiàn)的，當(dāng)不通過(guò)索引條件檢索數(shù)據(jù)時(shí)，行鎖就會(huì)升級(jí)成表鎖，我們知道表鎖會(huì)嚴(yán)重影響我們對(duì)整張表的操作，應(yīng)該避免這種情況。
- 控制事務(wù)的大小，減少鎖定的資源和鎖定的時(shí)間
下邊這個(gè)SQL異常相比很多并發(fā)比較高的系統(tǒng)里都會(huì)遇見(jiàn)，比如搶購(gòu)系統(tǒng)的日志中：
MySQLQueryInterruptedException: Query execution was interrupted
由于搶購(gòu)系統(tǒng)中，提交訂單業(yè)務(wù)開啟了事務(wù)，在并發(fā)環(huán)境中對(duì)一條記錄進(jìn)行更新操作的情況下，由于更新記錄所在的事務(wù)還可能存在其他操作，導(dǎo)致一個(gè)事務(wù)比較長(zhǎng)，當(dāng)大量請(qǐng)求進(jìn)入時(shí)，就可能導(dǎo)致一些請(qǐng)求同時(shí)進(jìn)入事務(wù)中，由于鎖的競(jìng)爭(zhēng)是不公平的，當(dāng)多個(gè)事務(wù)同時(shí)對(duì)一條記錄進(jìn)行更新時(shí)，極端情況下，一個(gè)更新操作進(jìn)去排隊(duì)系統(tǒng)后，可能會(huì)一直拿不到鎖，最后因超市被系統(tǒng)中斷，就會(huì)拋出上邊這個(gè)異常。
提交訂單需要?jiǎng)?chuàng)建訂單和扣減庫(kù)存，兩種不同順序的執(zhí)行方式，結(jié)果都一樣，但是性能確實(shí)不一樣的：
這兩種不同的執(zhí)行方式，雖然這些操作都在一個(gè)事務(wù)中，但是鎖的申請(qǐng)不在同一時(shí)間，鎖只有當(dāng)其他操作都執(zhí)行完成才會(huì)釋放鎖。扣減庫(kù)存是更新操作，屬于行鎖，如果先扣減庫(kù)存會(huì)影響到其他操作該數(shù)據(jù)的事務(wù)，所以我們應(yīng)該盡可能的避免長(zhǎng)時(shí)間持有該鎖，盡快的釋放鎖。
因?yàn)閯?chuàng)建訂單和扣除庫(kù)存不管先執(zhí)行哪一步都不影響業(yè)務(wù)，所以我們可以先執(zhí)行新增操作，把扣除庫(kù)存放到最后，也就是使用執(zhí)行順序1 ，來(lái)減少鎖的持有時(shí)間。
總結(jié)
MySQL 的并發(fā)事務(wù)調(diào)優(yōu)和 Java 的多線程編程調(diào)優(yōu)非常類似，都是可以通過(guò)減小鎖粒度和減少鎖的持有時(shí)間進(jìn)行調(diào)優(yōu)。在 MySQL 的并發(fā)事務(wù)調(diào)優(yōu)中，我們盡量在可以使用低事務(wù)隔離級(jí)別的業(yè)務(wù)場(chǎng)景中，避免使用高事務(wù)隔離級(jí)別。
在功能業(yè)務(wù)開發(fā)時(shí)，我們往往會(huì)為了追求開發(fā)速度，習(xí)慣使用默認(rèn)的參數(shù)設(shè)置來(lái)實(shí)現(xiàn)業(yè)務(wù)功能。例如，在 service 方法中，你可能習(xí)慣默認(rèn)使用 transaction，很少再手動(dòng)變更事務(wù)隔離級(jí)別。但要知道，transaction 默認(rèn)是 RR 事務(wù)隔離級(jí)別，在某些業(yè)務(wù)場(chǎng)景下，可能并不合適。因此，我們還是要結(jié)合具體的業(yè)務(wù)場(chǎng)景，進(jìn)行考慮。
