記錄分佈式一致性中的幾個概念

前言

這篇文章主要是記錄文，用於記錄一下最近看到的關於分佈式一致性的一些核心理念。

ACID

事務是由一系列對系統中數據進行訪問與更新的操做所組成的一個程序執行邏輯單元，狹義上的事務特指數據庫事務。事務具備ACID屬性。

Atomicity 原子性

事務中包含的各項操做在一次執行過程當中，只容許出現所有執行成功或是所有不執行兩種狀態。任何一項操做失敗都將致使整個事務失敗，同時其餘已經被執行的操做都將被撤銷並回滾。

Consistency 一致性

事務的執行不能破壞數據庫數據的完整性和一致性。一個事務執行以前和執行以後，數據庫都必須處於一致性的狀態。當數據庫只包含成功事務提交的結果時，就能說數據庫處於一致性狀態。而若是數據庫系統在運行過程當中發生故障，有些事務還沒有完成被迫中斷，這些未完成的事務對數據庫所作的修改有一部分已經寫入物理數據庫。這時數據庫就處於不一致狀態。

Isolation 隔離性

併發的事務是相互隔離的，一個事務的執行不能被其它事務干擾。即，不一樣事務併發操縱相同的數據時，每一個事務有各自完整的數據空間。事務的四個隔離級別以下：
Read Uncommited 讀未提交
容許髒讀，隔離界別最低。若是一個事務正在處理某一數據，並對其進行了更新，同時還沒有完成事務，即沒有進行事務提交。可是，與此同時，容許你另外一個事務可以訪問該數據。

Read Commited 讀已提交
和讀未提交的區別在於只容許獲取已經被提交的數據。可是沒法實現可重複讀取。即若是事務A在同一個事務中執行了兩次對同一條數據的select操做，同時事務B和C分別在第一條select以前和第二條select以前執行了對該數據的更新操做，那麼A的兩條select將獲得不一樣的數據。

Repeatable Read 可重複讀
在事務處理過程當中，屢次讀取同一個數據時，其值和事務開始時刻是一致的。可是該級別會出現幻讀。
幻讀:第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的所有數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，之後就會發生操做第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺同樣。

Serializable
要求全部的事務被串行執行，即事務只能一個接一個的進行處理，不能併發執行。

Durability 持久性

一個事務一旦提交，它對數據庫中對應數據狀態的變動就應該是持久性的。也就是說，即便發生系統崩潰，只要數據庫可以重啓，就必定可以將其恢復到事務成功結束時的狀態。

CAP

Consistency 一致性

在分佈式環境中，一致性是指數據在多個副本之間可以保持一致性。當一個系統在數據一致的狀態下執行更新操做後，應該保證系統的數據仍然處於一致的狀態。在分佈式系統中，若是可以在一個數據項的更新操做執行成功後，全部的用戶均可以讀取到其最新的值，那麼這樣的系統就被任務具備強一致性。

Availability 可用性

系統一直處於可用的狀態，對於每個操做請求總可以在有限時間內返回結果。有限時間是指可以在指定的響應時間內返回對應的結果，超過這個時間便可認爲系統不可用。指定的響應時間一般根據不一樣的系統有不一樣的標準。返回結果是指可以正常的相應結果，而不是看到系統錯誤等信息。

Partiion Tolerance 分區容忍性

分佈式系統在遇到任何網絡分區的故障的時候，仍然須要可以保持對外提供知足一致性和可用性的服務，除非整個網絡環境都發生了故障。

BASE

Basically Available 基本可用

分佈式系統在出現不可預知的故障的時候，容許損失可用性（不是說系統不可用）。好比響應時間比指定時間長一點，在功能上進行限流降級熔斷等等。

Sofa State 弱狀態

容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統的不一樣節點之間的數據副本之間進行數據同步的過程當中存在延時

Eventually Consistent 最終一致性

最終一致性強調系統中全部的數據副本，在通過一段時間的同步以後，最終可以達到一致的狀態。這是相對於實時強一致而產生的概念。

Casual Consistency 因果一致性
進程A在更新完某個數據以後通知了進程B，那麼進程B以後對該數據項的訪問都應該可以獲取到進程A更新後的最新值。即若是B依賴於A的更新，則更新必須順序進行。可是與進程A無因果關係的進程C則無這樣的限制。

Read Your Writes 讀己之所寫
進程A更新一個數據項以後，本身老是可以訪問到更新事後的最新值，而不是看到舊值。即一種特殊的因果一致性。

Session Consistency 回話一致性
系統保證在一個有效的回話中實現讀己之所寫一致性。也就說，執行更新操做後，客戶端可以在同一個回話中始終讀取到該數據項的最新值。

Monotonic Read Consistency 單調讀一致性
若是一個進程從系統中讀取出一個數據項的某個值後，那麼系統對於該進程後續的任何數據訪問都不該該返回更舊的值。

Monotonic Write Consistency 單調寫一致性
一個系統須要可以保證來自同一個進程的寫操做可以順序執行。

分佈式事務中的兩種角色

分佈式事務中的組件有兩種角色：

1. 協調者：統一調度全部分佈式節點的執行邏輯
2. 參與者：被調度的分佈式節點

Two-Phase Commit 2PC

階段一：提交事務請求（投票階段）

1. 事務詢問。協調者詢問全部參與者發送事務內容，詢問是否能夠執行事務提交操做，並等待各個參與者的相應
2. 執行事務。各參與者執行事務操做，並將undo和redo信息記入事務日誌中
3. 各參與者向協調者反饋事務詢問的響應

階段二：執行事務提交（執行階段）

根據參與者額反饋狀況來決定最終是否能夠進行事務的提交
狀況一：執行事務提交，即收到的反饋都是YES

1. 協調者發送提交請求
2. 事務提交：參與者收到提交請求以後，正式執行事務提交，提交以後釋放在整個事務執行期間佔用的事務資源
3. 反饋事務提交ACK結果
4. 完成事務

狀況二：中斷事務，即收到了No響應

1. 協調者發送回滾請求
2. 參與者利用undo日誌的信息進行事務回滾，並在回滾完成以後釋放在整個事務執行期間佔用的事務資源
3. 反饋事務回滾結果
4. 完成事務中斷

優勢：原理簡單，實現方便
缺點：同步阻塞，單點問題（協調者），太過保守

Three-Phase Commit 3PC

階段一：CanCommit

1. 事務詢問。協調者向全部參與者發送一個包含事務內容的canCommit請求，詢問是否能夠執行事務提交操做
2. 參與者根據自身狀況向協調者反饋事務詢問

階段二：PreCommit

根據CanCommit的回覆能夠產生如下兩種操做：
狀況一：執行事務預提交
假設收到的ACK均爲YES，則

1. 發送PreCommit請求
2. 參與者執行事務操做，並將Undo和Redo信息記錄到事務日誌中
3. 參與者向協調者反饋事務執行的響應

狀況二：中斷事務
假設收到了至少一個ACk爲NO或是等待超時

1. 協調者發出中斷請求
2. 參與者收到協調請求或是等待超時，都會中斷事務

階段三：DoCommit

狀況一：執行提交
收到PreCommit階段的所有ACK

1. 發送提交請求
2. 事務提交
3. 反饋事務提交結果
4. 完成事務

狀況二：中斷事務
假設協調者沒有收到所有的YES ACK則

1. 發送中斷請求
2. 事務回滾
3. 反饋事務回滾結果
4. 中斷事務

優勢：下降參與者阻塞範圍
缺點：參與者收到preCommit消息後，若是網絡出現分區，此時協調者所在的節點和參與者沒法進行正常的網絡通訊。這種狀況下，參與者依然會進行事務提交，從而出現數據的不一致性，

想要了解更多開發技術，面試教程以及互聯網公司內推，歡迎關注個人微信公衆號！將會不按期的發放福利哦~