a、強一致性：
r+w>n，建設有3個節點，每次讀時，讀2個節點並且資料一致；寫時，寫2個節點都成功才算寫成功。這種是強一致性。
2pc，3pc 多個節點都成功時，才算成功，否則進行回滾操作。
paxos，類似於2pc,解決分布式系統如何就某個值（決議）達成一致，進行投票選舉。是一種無主的節點的演算法。分布式的協調服務zookeeper就實現了這個演算法，保障一致性。mongodb中的集群方案replicaset也實現了類似的演算法。
b、 弱一致性（最終一致）：
由於分布式系統在資料同步時的網路延遲等等因素，無法保證副本資料和主節點時刻保持一致，當出現不一致的時，可以採用以下幾種策略保證最終一致性
gossip（cassandra，dynamo），是帶冗餘容錯演算法，也就是最終一致性的演算法，無法保證某時刻所有節點資料一致，它是乙個去中心化的部署方式，集群中每個節點維護一組狀態，狀態可以用key,value，外帶乙個版本號表示，版本大的比版本小的資料新，節點之間相互交流資料的版本資訊，並更新資料，類似病毒式的傳遞，這樣資料可以達到最終一致。cassandra就是採取這種策略來進行資料的同步,並且維護節點的健康狀態。
向量時鐘（dynamo），是一種資料不一致導致衝突的解決策略，系統採用樂觀鎖的策略，這樣對同乙個值進行操作時，就可能會出現多個版本，由向量時鐘來解決一致性；每個元素是（更新值的節點，序列號），每當更新乙個值時，都帶上這些資訊，從下圖可見，d3和d4出現資料的衝突，那麼在下次操作時，會由更新值的節點做衝突的解決。dynamo採用的就是這
時間戳(cassandra)，每次更新節點時，都帶上時間戳資訊，衝突的解決以時間戳最晚的為準。以cassandra為代表。
merle tree（cassandra，dynamo），在每個節點上針對每個區間裡的資料構造一棵merkle tree，這樣，在兩台節點進行資料比對時，從merkle tree的根節點開始進行比對，如果根節點一樣，則表示兩個副本目前是一致的，不再需要任何處理；如果不一樣，則遍歷merkle tree，定位到不一致的節點也非常快速，大大節省了比對時間以及資料的傳輸量。dynamo和cassandra中的副本同步採用這種方案。
最終一致性方案
訊息傳送一致性 微服務架構下，需要通過網路進行通訊，就自然引入了資料傳輸的不確定性，也就是cap原理中的p 分割槽容錯，而這裡的訊息傳送一致性是可靠訊息的保證。生成訊息的業務動作與訊息傳送的一致 e.g 如果業務操作成功，那麼由這個業務操作所產生的訊息一定會成功投遞出去，否則就丟失訊息 如上圖，保證...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
快取一致性解決方案
通常為了提公升使用者體驗，專案裡面一些熱點資料我們會把它放入快取裡面，以商品庫存為例我們就可以把商品對應的庫存資料放入redis，查詢資料時先去redis裡面找，沒有找到再訪問資料庫，如果庫存資料有更新就同時去更新redis的快取資料，以此達到減輕資料庫壓力。這種對快取資料的處理看似沒有問題，實際上...