一致性相關知識的索引

計算機能夠提供的價值

• 平台價值
• 提供信息交換的平台，讓發布方可以通過平台發布信息，傳遞給很多人
• 提供交易的平台，讓多方可以在線交易，執行契約
• 提供信息檢索的平台，讓海量的數據能夠快速被檢索到
• 人工智慧的價值：實現獲取信息，推理，到決策的過程。做為機器人，和其他肉身的人類在平台上協作

海量的信息獲取這一塊（右側那個紅框），在互聯網的推動下有了極大的發展。所謂互聯網公司的海量流量的牛b技術，主要是把索引和分散式搞好了。可以極強地進行水平擴展，高效地檢索信息。

左側的兩個紅框，就是交易平台。它在這個體系下提供的作用就是，向上承接多種角色的交易請求（寫入操作）。協調多方，解決角色之間的衝突。然後把交易的結果發布給信息檢索平台。當沒有衝突需要解決的情況下，交易平台就退化成了一個簡單的信息交換平台。

交易平台

交易平台為了提供它的兩個業務價值，對一致性提出了兩個需求：

• 一致性讀取：最強的一致性讀取需求就是線性一致性讀取。要求寫入成功之後，立馬就可以被讀取到。這個前和後是說的是牆上的時間。
• 一致性寫入：最強的一致性寫入的需求就是線性一致性寫入。寫入操作分成read-write兩個階段，要求read的時候可以看到所有之前已經write成功的改動。然後要求write如果要成功，不能在read-write中間有其他的寫入插入進來。

多對象

多對象寫入有兩種情況

• 多個對象對應真實世界中的不同實體：比如轉賬時的多個賬戶，對應了多個用戶的錢包。
• 真實世界的同一個實體在虛擬空間的多種投影：因為計算機的檢索計算效率，需要用多種對象來代表同一個東西。比如一個3個欄位的對象，按照每個欄位做一次排序，就可以有3個副本。不同的排序滿足了不同欄位的檢索效率的需求。

一個實體被投影成了多個對象之後就引入了複製問題，或者叫「冗餘欄位」問題

這種冗餘又可以分為兩種：

• 需要強一致的冗餘：比如發單的時候判斷是否有未支付訂單。我們需要維護訂單狀態和是否有未支付訂單這樣的冗餘關係。這個需要強一直。
• 需要弱一致的冗餘：訂單狀態和乘客歷史訂單與司機歷史訂單之間不需要太強的一致性。

保持一致性的兩種思路

• 寫入時就判斷是否一致：也就是能檢測衝突，並反饋是否寫入成功
• 讀取時「歸總」寫入的情況，得到一個一致的視圖：當業務邏輯本身沒有衝突檢測的需求（比如就是+1，無論什麼前提條件都+1），可以隨意寫入，總是成功。讀取的時候讀多個副本內容，merge出結果。比如CRDT的流派

寫入時保持一致性的四種方法

• 用CPU保障單機的一致性，故障切換等場景下容忍錯誤
• 排隊到單個線程里去處理
• mfence/sfence 保證一致性讀
• lock cmpxchg 保證一致性寫
• 代表資料庫：redis
• 對單對象的改動在一個log里進行排序
• shared log：共享一份全局的日誌
• 讓歷史靜止（v版本，以及v-1, v-2, .. 0的版本都靜止），然後讀 v 版本
• 讀完了之後進行業務邏輯版判斷，決定 v+1 版本進行寫入
• 讓歷史靜止由占坑來實現。坑要保證自己只能被佔一次。
• 單對象的模型，需要用「對賬」機制來保證多個對象之間的數據一致性。
• 把多個對象靜態捆綁成一個對象，然後把操作在一個log里排序
• zookeeper/etcd為代表的資料庫
• hyperledge的read-write set就是一種對這樣場景下的優化
• 把多個對象動態捆綁成一個對象，然後改完了，再解綁
• spanner/cockroach/tidb 的模型
• 多key的背後是多log
• 多key之間的事務靠2pc提交。動態捆綁對象成一個就是靠2pc。

推薦閱讀：