[[405728]]

日常Bug排查系列都是一些簡單Bug排查，筆者將在這里介紹一些排查Bug的簡單技巧，同時(shí)順便積累素材_。

應(yīng)用Commit報(bào)錯(cuò)并不一定回滾

事實(shí)上，這篇文章并沒有什么排查過程。但這個(gè)問題卻又是筆者經(jīng)常遇到的。

筆者僅僅是想闡述一下當(dāng)我們?cè)谑聞?wù)Commit報(bào)錯(cuò)時(shí)候，數(shù)據(jù)庫中的數(shù)據(jù)并不一定會(huì)是我們以為的回滾狀態(tài)。筆者舉個(gè)例子:

在這種情況下，很明顯的DB的數(shù)據(jù)肯定是處于已經(jīng)提交的狀態(tài)。而如果App認(rèn)為是回滾狀態(tài)，并基于這個(gè)信息去做操作的話，很明顯會(huì)導(dǎo)致數(shù)據(jù)不一致。

非IO or 超時(shí)異常 也不一定回滾

可能有人會(huì)問了，是不是僅僅是IO異?；蛘叱瑫r(shí)異常才會(huì)出現(xiàn)這種不一定回滾的問題呢?這里還真不一定，筆者在一次Case中，就發(fā)現(xiàn)Oracle在commit的時(shí)候返回死鎖異常時(shí)候，數(shù)據(jù)庫內(nèi)部的commit竟然也成功了!這就牽涉到數(shù)據(jù)庫內(nèi)部的處理了。

應(yīng)用應(yīng)該怎么做呢?

事實(shí)上，由于數(shù)據(jù)庫保證了原子性。所以我們?cè)谟龅竭@種情況時(shí)候，需要從數(shù)據(jù)庫中重建狀態(tài),而不是依賴現(xiàn)在應(yīng)用里面的信息。所以遇到異常直接將流程結(jié)束，然后等定時(shí)任務(wù)等補(bǔ)單操作是個(gè)比較簡單安全的做法。

當(dāng)然，數(shù)據(jù)庫中重建狀態(tài)時(shí)候，也要考慮到上一個(gè)相應(yīng)的commit還在commit的過程中,只不過這個(gè)commit非常慢而已。由于我們更新數(shù)據(jù)或者最終判斷的時(shí)候往往會(huì)鎖住數(shù)據(jù),而數(shù)據(jù)庫一般都是采用了二階段鎖(S2PL)。

在上一個(gè)commit成功提交之后，我們對(duì)相應(yīng)數(shù)據(jù)的操作才會(huì)執(zhí)行下去。所以只要小心的控制好鎖的范圍，數(shù)據(jù)一致性還是能保證的。

總結(jié)

Commit報(bào)錯(cuò)但事務(wù)并沒有回滾，這個(gè)雖然有點(diǎn)反直覺，但這確是在產(chǎn)線真實(shí)存在的，尤其在數(shù)據(jù)庫壓力大的時(shí)候極易出現(xiàn)。這個(gè)坑在我們編寫代碼的時(shí)候需要牢記!

本文轉(zhuǎn)載自微信公眾號(hào)「解Bug之路」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系解Bug之路公眾號(hào)。