嚶嚶嚶(╥╯^╰╥)...有看球的胖友嘛？今年的世界盃真的是各種神操作，各種跌宕起伏。

“31歲的梅西就站在那裡，看著姆巴佩像一匹脫韁的野馬，肆意衝殺於潘帕斯草原，眼裡滿是自己19歲的樣子...”

好了，迴歸正題，

把個人理解的幾個概念做了一個總結，更貼近開發工作，更直白通俗的總結(意味著不嚴謹，但能懂ღ( ´･ᴗ･` )比心)。

ACID模型

單個關係型數據庫就是用這個模型來保障高一致性和可用性的。

Atomicity原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。 Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。 Isolation隔離層. 事務將假定只有它自己在操作數據庫，彼此不知曉。 Durability. 一旦事務完成，就不能返回。

BASE理論

和ACID相反，分佈式事務中我們無法做到強一致。雖然可能不一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使分佈式系統數據達到最終一致性。

1. Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)
2. Soft state軟狀態 狀態可以有一段時間不同步，異步。
3. Eventually consistent最終一致，最終數據是一致的就可以了，而不是時時高一致。

CAP原則

分佈式系統中，數據一致性和響應速度是成反比的。要想多個系統數據一致，就需要時間進行同步；要想盡快響應用戶，就要接受數據不一致的情況(往往就是業務權衡)。

CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出分佈式WEB服務無法同時滿足一下3個屬性：

數據一致性(consistency)：

如果系統對一個寫操作返回成功，那麼之後的讀請求都必須讀到這個新數據；如果返回失敗，那麼所有讀操作都不能讀到這個數據，對調用者而言數據具有強一致性。

1. 簡單理解: 要往十個系統裡每個系統都增加一條數據，每個子系統上面都進行修改成功，這樣就保證了數據一致，但是時間也會延長；

服務可用性(availability)

所有讀寫請求在一定時間內得到響應

1. 簡單理解: 上面已經說到，為了保證數據一致性，我們需要延長時間。那為了減少響應時間，我們可能先在一個系統內增加一條數據，剩下的九個系統異步去添加，這就是犧牲數據一致性，換取可用性；

分區容錯性(partition-tolerance) - 可靠性

在網絡分區的情況下，被分隔的節點仍能正常對外服務，簡單可理解為“可靠性”（兩個系統外界看來就是整體，如果系統不能通信了，成為分區。 如果不能保證分區容錯性，則節點不能正常服務，不能服務就談不上什麼事務了，所以分區容錯性是肯定要保證的）；

1. 分區容錯性 的理解：多個系統組成一個分佈式系統，外界看來這個系統是一個整體，一個區域。

2. 但是內部如果出現網絡不通的問題，多個子系統就變成了孤島，變成了多個分區，分區容錯性就是指這種情況是，每個子系統要能夠適應這種問題，能正常提供服務，雖然數據可能沒同步到其他子系統，但總比系統不能訪問要好 。

總結

分佈式事務會結合上面三個概念進行實現，在實際開發中，就是根據具體業務在 數據一致性 和 服務可用性 兩者之間進行權衡。

最後，祝黨97歲生日快樂！

美的人還在上班，顏值越高，責任越大（笑出豬聲，哈哈哈哈哈哈）

閱讀更多 JAVA鼓勵師 的文章

關鍵字: 姆巴 佩像 加州大學伯克利分校