在傳統的數據中，有ACID四大原則，在分布式中也有對應的CAP理論和BASE理論，這些都是分布式理論的基礎。
更多內容參考：大數據學習之路
ACID
ACID分別是Atomicity 原子性、Consistency 一致性、Isolation 隔離性、Durability 持久性，有了這幾個特性，就保證了數據庫的可靠。
原子性
原子性代表一系列的操作要么全做，要么全不做。比如，在銀行轉賬，從一個賬號扣錢，另一個賬號加錢，這兩個操作必須同時進行。否則就會出現賬目對不上的情況。
一致性
一致性官方的描述是，事務執行后必須是從一個一致性狀態轉到另一個一致性狀態。通俗點說就是保證整個系統在操作完成后，雖然處於不同狀態，但仍保持一致。比如在轉賬情境中，從一個賬號轉出500，轉入另一個賬號，那么整個系統的金額不應該有變化。
隔離性
隔離性意味着多個並發之間是不可見的，相互隔離不被打擾。隔離性在數據庫操作中還是很重要的，如果不考慮隔離性，可能會出現下面的問題：
- 臟讀：事務T1讀取了事務T2未提交的數據，結果事務T2回滾了，T1拿到了一個臟數據
- 不可重復讀：事務T1讀取數據后，緊接着事務T2就更新了數據，事務T1再次讀取的時候發現數據不一致了
- 幻讀：這種一般發生在大批量修改的時候，比如事務T1把所有的數據從1修改到了2，結果修改的過程中，事務T2插入了一條新數據1。最后檢查數據發現有一條數據沒有修改過來。
針對這幾種情況，數據庫如Mysql提供了幾種事務的隔離級別：
- Serializable (串行化)：可避免臟讀、不可重復讀、幻讀的發生。
- Repeatable read (可重復讀)：可避免臟讀、不可重復讀的發生。
- Read committed (讀已提交)：可避免臟讀的發生。
- Read uncommitted (讀未提交)：最低級別，任何情況都無法保證。
持久性
這種最容易理解了，事務提交后，結果就保存不變了。
CAP
在分布式系統中，也有類似ACID的特性，那就是CAP，他們分別是：
- Consistency 一致性，強調進群節點中數據一致。在分布式中一致性又包括強一致性和弱一致性，強一致性就是指在任何時刻任何節點看到的數據都是一樣的；弱一致性一般實現是最終一致性，即剛開始可能存在差異，但隨着時間的推移，最終數據保持一致。
- Availability 可用性，強調集群在任何時間內都正常使用
- Partition Tolerance 分區容錯性，即使某一部分集群壞掉，另一部分仍能正常工作。
這三個特性只能滿足其中兩個，犧牲另一個。大部分系統也都是如此：
一般來說分布式集群都會保證P優先，即集群部分節點壞死不影響整個集群的使用，然后再去追求C和A。因為如果放棄P——分區可用性，那不如就直接使用多個傳統數據庫了。事實上，很多微服務分庫分表就是這個道理。
如果追求強一致性，那么勢必會導致可用性下降。比如在Master-Slave的場景中，Master負責數據寫入，然后分發給各個節點，所有節點都寫入成功，才算寫入，這樣保證了強一致性，但是延遲也會隨之增加，導致可用性降低。
因此在可用性和一致性之間，就出現了各種解決方案，如時序一致性、最終一致性等等。
BASE
前面由於分布式在CAP面前各種糾結，因此有人總結出了一套適合分布式的理論——BASE：
- BA，Basically Available 基本可用，比如降低性能要求、或者功能特性來保證整體的服務可用。比如服務的降級、增加延遲、等待等等。
- S，Soft State 軟狀態，允許出現中間狀態，比如節點的不同副本之間同步存在延遲
- E，Eventual Consistency 最終一致性，具體的方案有很多，如因果一致性、讀己一致性、會話一致性、單調讀一致、單調寫一致。
對於這幾種一致性，可以簡單的說一下：
- 因果一致性：進程B對進程A有依賴關系，那么B讀取到的應該總是A更新后的值
- 讀己一致性：進程A更新某個值后，它自己讀到的應該是最新的值
- 會話一致性：在會話中進行操作，需要保證總是讀取到最新的值
- 單調讀一致：從系統讀取某個值后，不應該讀取到比它還舊的值
- 單調寫一致：同一個進程對系統的寫操作，需要保證順序