ACID屬性區別

　　事務是指對系統進行的一組操做，爲了保證系統的完整性，事務須要具備ACID特性，具體以下：

1. 原子性（Atomic）
     一個事務包含多個操做，這些操做要麼所有執行，要麼全都不執行。實現事務的原子性，要支持回滾操做，在某個操做失敗後，回滾到事務執行以前的狀態。
     回滾其實是一個比較高層抽象的概念，大多數DB在實現事務時，是在事務操做的數據快照上進行的（好比，MVCC），並不修改實際的數據，若是有錯並不會提交，因此很天然的支持回滾。
     而在其餘支持簡單事務的系統中，不會在快照上更新，而直接操做實際數據。能夠先預演一邊全部要執行的操做，若是失敗則這些操做不會被執行，經過這種方式很簡單的實現了原子性。
2. 一致性（Consistency）
     一致性是指事務使得系統從一個一致的狀態轉換到另外一個一致狀態。事務的一致性決定了一個系統設計和實現的複雜度。事務能夠不一樣程度的一致性：
     強一致性：讀操做能夠當即讀到提交的更新操做。
     弱一致性：提交的更新操做，不必定當即會被讀操做讀到，此種狀況會存在一個不一致窗口，指的是讀操做能夠讀到最新值的一段時間。
     最終一致性：是弱一致性的特例。事務更新一份數據，最終一致性保證在沒有其餘事務更新一樣的值的話，最終全部的事務都會讀到以前事務更新的最新值。若是沒有錯誤發生，不一致窗口的大小依賴於：通訊延遲，系統負載等。
     其餘一致性變體還有：
     單調一致性：若是一個進程已經讀到一個值，那麼後續不會讀到更早的值。
     會話一致性：保證客戶端和服務器交互的會話過程當中，讀操做能夠讀到更新操做後的最新值。
3. 隔離性（Isolation）
     併發事務之間互相影響的程度，好比一個事務會不會讀取到另外一個未提交的事務修改的數據。在事務併發操做時，可能出現的問題有：
     髒讀：事務A修改了一個數據，但未提交，事務B讀到了事務A未提交的更新結果，若是事務A提交失敗，事務B讀到的就是髒數據。
     不可重複讀：在同一個事務中，對於同一份數據讀取到的結果不一致。好比，事務B在事務A提交前讀到的結果，和提交後讀到的結果可能不一樣。不可重複讀出現的緣由就是事務併發修改記錄，要避免這種狀況，最簡單的方法就是對要修改的記錄加鎖，這回致使鎖競爭加重，影響性能。另外一種方法是經過MVCC能夠在無鎖的狀況下，避免不可重複讀。
     幻讀：在同一個事務中，同一個查詢屢次返回的結果不一致。事務A新增了一條記錄，事務B在事務A提交先後各執行了一次查詢操做，發現後一次比前一次多了一條記錄。幻讀是因爲併發事務增長記錄致使的，這個不能像不可重複讀經過記錄加鎖解決，由於對於新增的記錄根本沒法加鎖。須要將事務串行化，才能避免幻讀。
     事務的隔離級別從低到高有：
     Read Uncommitted：最低的隔離級別，什麼都不須要作，一個事務能夠讀到另外一個事務未提交的結果。全部的併發事務問題都會發生。
     Read Committed：只有在事務提交後，其更新結果纔會被其餘事務看見。能夠解決髒讀問題。
     Repeated Read：在一個事務中，對於同一份數據的讀取結果老是相同的，不管是否有其餘事務對這份數據進行操做，以及這個事務是否提交。能夠解決髒讀、不可重複讀。
     Serialization：事務串行化執行，隔離級別最高，犧牲了系統的併發性。能夠解決併發事務的全部問題。
     一般，在工程實踐中，爲了性能的考慮會對隔離性進行折中。
4. 持久性（Durability）
     事務提交後，對系統的影響是永久的。

 

備註：一致性更強調一個事物的完整，隔離性強調的是不一樣事物間的併發處理。一致性包括兩方面：

1.數據庫機制層面

　　數據庫層面的一致性是，在一個事務執行以前和以後，數據會符合你設置的約束(惟一約束，外鍵約束,Check約束等)和觸發器設置.這一點是由SQL SERVER進行保證的.

2.業務層面

　　對於業務層面來講,一致性是保持業務的一致性.這個業務一致性須要由開發人員進行保證.不少業務方面的一致性能夠經過轉移到數據庫機制層面進行保證.好比，產品只有兩個型號，則能夠轉移到使用CHECK約束使某一列必須只能存這兩個型號.