??我是平也，這有一個專注Gopher技術成長的開源專案「go home」
背景介紹
想必事務大家都已經非常熟悉了，它是一組SQL組成的一個執行單元，要么全執行要么全不執行，這也是它的一個特性——原子性，而事務的應用場景也非常廣泛，最經典的就是轉賬問題，A給B打錢，不能出現A錢扣了B還沒收到的狀況，否則業務就亂套了，
事務的特性
于是呢，根據用戶對這些場景的嚴苛要求，總結出了事務應該具備的四個特性，分別是原子性、一致性、隔離性、持久性，簡稱事務的ACID屬性，
原子性
Atomicity，事務是一個最小的執行單位，事務里面的SQL要么全執行，要么全不執行，就拿A與B轉賬為例，一條陳述句從A里扣錢，另一條陳述句往B身上加錢，如果這兩條陳述句不能全部執行，而是成功了一部分，那事務就沒有存在的意義了，
隔離性
Isolate，顧名思義就是將事務與另一個事務隔離開，為什么要隔離呢？如果一個事務正在操作的資料被另一個事務修改或洗掉了，最后的執行結果可能無法達到預期，如果沒有隔離性還會導致其他問題，稍后會有所說明，
持久性
Durable，意為事務完成了對資料的修改之后，修改的結果是永久性生效的，
一致性
Consistent，把一致性放在最后講的原因是前三個比較容易理解，而一致性的概念很模糊，
一致性是指事務使得應用系統從一個正確的狀態到另一個正確的狀態，
知乎上面一個高贊回答的很特別，原子性、隔離性、持久性是資料庫事務的基本特征，而一致性是由AID這三個特征來保證的，
那么怎么理解這句話呢？還拿轉賬為例，如果A手里有100元，轉給B120元，顯然A手里的錢不夠扣，假如你給金額這一列設定了不能小于0的約束，那么在事務執行的時候監測到約束沒被滿足，就會回滾，這時可以說事務保證了一致性，同樣的，如果你沒有添加約束，而是在業務層做了校驗，并做了回滾，那么也可以說事務保證了一致性，那如果資料庫和業務層都沒有做約束呢，A的錢不就變為負數了嗎？這實際上也是保證了一致性，因為執行前后并沒有破壞任何約束，它的狀態一直都是正確的，
事務并發帶來的問題
前面講到了事務的隔離性，如果要提升系統的吞吐量，當有多個任務需要處理時，應當讓多個事務同時執行，這就是事務的并發，既然事務存在并發執行，那必然產生同一個資料操作時的沖突問題，來看一下都會出現什么問題，
更新丟失
Lost Update，當兩個事務更新同一行資料時，雙方都不知道對方的存在，就有可能覆寫對方的修改，比如兩個人同時編輯一個檔案，最后一個改完的人總會覆寫掉前面那個人的改動，
臟讀
Dirty Reads，一個事務在執行時修改了某條資料，另一個事務正好也讀取了這條資料，并基于這條資料做了其他操作，因為前一個事務還沒提交，如果基于修改后的資料進一步處理，就會產生無法挽回的損失，
不可重復讀
Non-Repeatable Reads，同樣是兩個事務在操作同一資料，如果在事務開始時讀了某資料，這時候另一個事務修改了這條資料，等事務再去讀這條資料的時候發現已經變了，這就是沒辦法重復讀一條資料，
幻讀
Phantom Read，與上方場景相同，事務一開始按某個查詢條件沒查出任何資料，結果因為另一個事務的影響，再去查時卻查到了資料，這種就像產生幻覺了一樣，被稱作幻讀，
事務的四種隔離級別
首先，更新丟失這種問題應該是由應用層來解決的，因為資料庫沒有辦法控制用戶不去更新某條資料，但是另外三個問題是可以得到解決的，既然有方案解決解決它不就好了，干嘛還要設定這么多隔離級別呢？
剛才說了，如果我們要性能好、吞吐量提升，那就不得不付出一些代價，如果要做到完全沒有副作用，那么就只需要讓事務排隊執行就好了，一個一個執行絕對不會出現臟讀幻讀的問題，但是這樣會導致資料庫處理的非常慢，那怎么辦呢？官方唯一能做的就是給你提供各種級別的處理方式，由你根據具體業務場景選擇，于是就有了隔離級別，
讀未提交 Read uncommitted
讀未提交其實就是事務沒提交就可以讀，很顯然這種隔離級別會導致讀到別的還沒提交的資料，一旦基于讀到的資料做了進一步處理，而另一個事務最侄訓滾了操作，那么資料就會錯亂，而且很難追蹤，總的來說說，讀未提交級別會導致臟讀，
讀提交 Read committed
顧名思義就是事務提交后才能讀，假設你拿著銀行卡去消費，付錢之前你看到卡里有2000元，這個時候你老婆在淘寶購物，趕在你前面完成了支付，這個時候你再支付的時候就提示余額不足，但是分明你看到卡里的錢是夠的啊，
這就是兩個事務在執行時，事務A一開始讀取了卡里有2000元，這個時候事務B把卡里的錢花完了，事務A最終再確認余額的時候發現卡里已經沒有錢了，很顯然，讀提交能解決臟讀問題，但是解決不了不可重復讀，
Sql Server，Oracle的默認隔離級別是Read committed，
可重復讀 Repeatable read
看名字就看出來了，它的出現就是為了解決不可重復讀問題，事務A一旦開始執行，無論事務B怎么改資料，事務A永遠讀到的就是它剛開始讀的值，那么問題就來了，假設事務B把id為1的資料改成了2，事務A并不知道id發生了變化，當事務A新增資料的時候卻發現為2的id已經存在了，這就是幻讀，
MySQL的默認隔離級別就是Repeatable read，
串行化 serializable
這個就是最無敵的存在了，所有的事務串起來一個個執行，因為沒有并發的場景出現了，什么幻讀、臟讀、不可重復讀統統都不存在的，但是同樣的，基本并發能力會非常差，最終，到底什么隔離級別完全要根據自己的業務場景選擇，沒有最好的，只有最適合的，
表格比較
| 隔離級別 | 臟讀 | 不可重復讀 | 幻讀 |
|---|---|---|---|
| Read uncommitted | 是 | 是 | 是 |
| Read committed | 否 | 是 | 是 |
| Repeatable read | 否 | 否 | 是 |
| serializable | 否 | 否 | 否 |
感謝大家的觀看，如果覺得文章對你有所幫助，歡迎關注公眾號「平也」，聚焦Go語言與技術原理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/24415.html
標籤：Go
上一篇：golang實作常用集合原理介紹