分布式一致性

分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。

分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。

理想狀態下，當然希望分布式系統能夠實現資料一致性並且讓各個方面都滿足要求，但這是難以達到的，例如如果在更新資料時通過將其他動作阻塞只進行寫入操作，若寫入涉及大量操作且耗時那麼必然影響系統的整體可用性。因此，對於分布式一致性會分為不同的級別，以適應不同的環境。

強一致性

寫入與讀取資料一致，效能最弱。

弱一致性

寫入成功後，不能立即讀取到最新的資料，也不保證多久能達到一致。

弱一致性又分為會話一致性和使用者一致性。

會話一致性只保證寫入值在通過會話客戶端讀取到一致的值。

使用者一致性值保證寫入的值同個使用者能立即讀取到。

最終一致性

資料不保證一致性，只能確保會在一定時間內達到資料一致性的狀態。

在分布式系統中有些事務操作需要跨越節點，為保持事務的一致性，需要協調的元件進行排程，並決定是否將事務進行提交，因此提交的策略也分為二階段提交和三階段提交。

2pc二階段提交是分布式架構下節點進行事務處理時，為保持原子性和一致性而制定的演算法。

階段一:

1.事務詢問（協調者向參與者傳送事務內容）

2.執行事務(各節點執行事務操作，將undo和redo寫入事務日誌)

3.各節點向協調者反饋事務詢問（節點執行成功則反饋yes，表示事務可執行，失敗則為no）

階段二:

階段二協調者會根據各節點反饋情況決定是否進行事務提交。

1.傳送提交請求(向各節點發出commit請求)

2.事務提交(節點接收commit請求後執行事務操作，提交並釋放資源)

3.反饋事務提交結果

4.完成事務(協調者接收到所有節點反饋後，完成事務)

如果節點向協調者反饋no，或等待超時，協調者沒有接收到所有節點的反饋響應則中斷事務。

中斷事務過程:

1.傳送回滾請求

2.事務回滾(節點接收rollback請求之後 ，利用undo執行回滾並釋放資源)

3.反饋事務回滾結果

4.中斷事務

以上時二階段提交的過程處理邏輯。分為事務提交和事務中斷。圖示如下:

優缺點:

原理簡單，實現方便(優點)

同步阻塞，單點問題，腦裂，太保守(缺點)

三階段提交將二階段提交事務過程分為兩個階段。

階段一:提交

1.事務詢問

2.各節點反饋事務詢問的響應

分布式一致性

分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...

分布式一致性方案

首先，先說一下。老外提出了乙個快取更新套路，名為 cache aside pattern 其中就指出 不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生 快取剛好失效 請求a查詢資料庫，得乙個舊值 請求b將新值寫入資料庫 請求b刪除快取 請求a將查到的舊值寫...

分布式一致性方案

首先，先說一下。老外提出了乙個快取更新套路，名為 cache aside pattern 其中就指出 失效 應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。命中 應用程式從cache中取資料，取到後返回。更新 先把資料存到資料庫中，成功後，再讓快取失效。不是的。假設這...