一致性

線程安全：多個線程之間的切換不會致使該接口的執行結果存在二義性。

分佈式一致性：數據的多份副本，當對一個副本進行修改時，其它的副本的值也要與其保持一致。

數據庫一致性：事務執行的結果必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。保證數據庫一致性是指當事務完成時，必須使全部數據都具備一致的狀態。

 

線程不徹底則分佈式一致性是絕對沒法保證的。線程安全，也不必定能夠保證分佈式一致性。因此分佈式一致性是一種更復雜的要求。

線程不安全則數據庫的一致性絕對沒法保證。數據庫的一致性其實就是數據庫自己的線程安全性嗎？

隔離級別：

串行：沒有線程安全問題，數據變動依賴的狀態是事務開始的狀態。

RR: 併發執行，存在線程安全問題，數據變動依賴的狀態是事務開始的狀態，不會受到其餘事務的影響。可是對新增數據無能爲力。

RC: 併發執行，存在線程安全問題，數據變動依賴的狀態是會受其餘事務影響的。

Read not commit: 併發執行，存在線程安全問題，數據變動依賴的狀態是會受其餘事務影響的。

 

因此，事務最多隻是提供了線程安全，必定的數據隔離，還有原子性。這些沒法保證能夠達到分佈式的數據一致性。

在考慮應用的數據一致性的時候，須要額外考慮達到目標的手段。

 

分佈式一致性的挑戰：

1. 分佈性：數據/機器的空間分佈。

2. 對等性：沒有主從之分

3.併發性：線程安全

4.缺少全局時鐘：沒法根據統一的時間標準來判斷哪一個操做先發生。

5.網絡通訊的不穩定性。

 

分佈式一致性是很是複雜的，解決方案根據不一樣的場景每每也不同：

1.隊列，把key打散，橫向擴容。單個隊列順序消費

2.全量數據的append寫入+timestamp

3.分佈式鎖（redis，mysql）

4.version-id+CAS

5. mysql + 惟一鍵

 

惟一約束真的有必要在物理層作強約束嗎？ 單單在邏輯層的保證靠譜嗎？