分佈式事務？咱先弄明白本地事務再說 - ACID

 

 

過去一段時間面試的同窗，對於數據庫事務，能夠按照配置正常使用，但不少都沒法講清楚和理解數據庫事務這個東西真正的意義，以及互聯網興起之後，當今數據庫在ACID面前面臨怎樣的問題和抉擇。

事務，是各大單機SQL數據庫廠商包括Oracle、IBM DB2等，早在上世紀80年代提出的一個解決 數據併發操做處理的模型 ，旨在知足多用戶（多線程、進程）對數據操做的場景下，依然能保證邏輯正確執行，狀體持久，且各大廠商提出，並在事務實現上都遵循事務的 ACID 4個特性。

回顧ACID

 

 

 

一個模塊，是多個獨立的功能邏輯的組合，每一個功能包含多個操做步驟，包括IO、計算、數據庫等操做，必須保證每一步都被執行，且執行正確，這個功能和模塊纔是可用，可交付的。

 

 

 

那麼，如何保證這些操做的完整性，就是Atomic，定義爲一個原子操做，所有執行且成功，或者所有失敗都不執行（回滾），原子操做若是成功，那狀態就必須持久，被稱爲數據庫的Durability，持久性。

原子性A、持久性D，這倆個都比較好理解，定義了事務的邊界，行爲的開始和行爲的結束。

A、D定義了事務的邊界，那一致性C、隔離性I，就是對事務中間狀態的管理，

 

一致性，也能夠理解爲是數據的完整性，數據的有效性，咱們舉例來講明什麼是一致性，以及事務是如何保證一致性的，

• 一個帳戶減100，另外一個帳戶加100的時候，程序異常crash了，這時候就出現數據的不一致狀況，破壞了有效性，這個問題能夠由Atomic來保證；
• 一個原子操做在執行的過程當中，涉及多個數據變動的中間狀態的保護，例如把A帳戶減100，在加到B帳戶完成這個原子操做以前，此時，其餘線程對A讀的操做就有可能獲取到A少100的這個中間狀態，這種狀況是否容許發生，由Isolation來保證；
• 數據庫延遲約束，例如數據字段的類型、空值、關係、數據範圍、主鍵惟一性等這些合法性的檢查都是由Durability來保證，在事務commit時，發現數據不合法，是沒法提交成功的。

 

因此，綜上所述，一致性C，是數據狀態的正確變換的保證，AID，是實現C的手段，也是咱們真正要追求的目標。

 

而，隔離性I的設定，就是對一致性C不一樣程度的破壞，事實上，若是咱們順序對數據進行讀寫，ACD是徹底可用保證的，但這樣效率會很是的低下，那，咱們是要嚴格的一致性，仍是更高的效率，數據庫專家們把這個決定權交給了用戶，因此，咱們看到，ACID當中，只有隔離性I是用戶能夠選擇的，能夠自定義的。
隔離性包括 串行讀、讀已提交、重複讀、讀未提交 等幾種策略，性能由低到高，讓用戶在不一樣的使用場景，選擇合適的隔離策略，在一致性和性能之間平衡，取得最好的綜合表現。

 

小結

本文主要介紹了事務和事務的幾個特性，解釋了ACID的由來和之間的關係，

總的來講，ACID的核心是C，你們其實都是爲獲得C而提出的不一樣緯度的限制和規範，A肯定一個功能的完整性，D對狀態負責，I能夠說是C的等級係數，不一樣的I的策略，會出現不一樣的級別的C，AID是數據庫自己的功能特性，C由業務層把控，要嚴格的C，就設置完整的數據庫約束和串行隔離，反之，要寬鬆的C，就放開數據庫的約束，使用讀未提交的隔離策略，存在即合理，後者更適用於互聯網高併發對一致性要求不高的場景，例如分佈式的AP系統，能夠保證服務總體的響應時間和服務的可用性。