1、一致性概念：
指分散式服務系統之間的弱一致性，包括應用系統的一致性和資料的一致性.
資料量大，高併發要求高，強計算能力，響應速度要求快，等的網際網路要求場景下，服務節點開始池化，開始出現容器應用和資料拆分，分而治之的思想和邏輯
水平拆分和垂直拆分
2、解決一致性問題的模式和思路
（1）酸鹼平衡理論
①ACID（酸）
原子性，一致性，隔離性，永續性。
關係型資料庫事務處理保證強一致性通常是通過多版本控制協議（MVCC）來實現的
下訂單和扣庫存不一致問題可以將訂單和庫存放入同一資料庫分片，通過關係型資料庫事務處理的4個基本要素ACID就可以解決這一不一致問題。
②CAP（帽子原理）：分散式系統的CAP原理
一致性，可用性，分割槽容忍性
分散式的服務系統都需要滿足分割槽容忍性（允許網路上部分訊息丟失），但是必須在一致性（所有系統節點在同一時刻讀取的資料必須是最新的資料副本）和可用性（好的響應效能，任何故障狀態下，服務都會在有限時間內處理完成並進行響應）執行權衡，只能滿足以上兩點，不能三者兼顧。
③BASE（鹼）
BASE思想解決了CAP提出的分散式系統一致性和可用性不可兼得的問題。
BA：基本可用，S：軟狀態，狀態可以在一段時間內不同步，E：最終一致性；
軟狀態是實現BASE思想的方法，基本可用和最終目標一致是目標；
解決訂單和庫存的一致性問題，對複雜的分散式事務進行拆解，記錄中間所有步驟的軟狀態，有問題時可以根據記錄的狀態繼續執行任務，達到最終一致；
總結：
向上擴充套件，升級硬體，使用關係型資料庫。
使用開源的關係型資料庫，進行水平伸縮和分片，將相關資料分到資料庫的同一個分片上，保證事務執行。
如果無法將相關資料分到同一個片上，就需要實現最終一致性，記錄事務的軟狀態。
（2）分散式一致性協議
DTS分散式事務處理模型：
包含四個角色：應用程式，事務管理器，資源管理器和通訊管理器
事務管理器是統管全域性的管理者（協調者），資源和通訊管理器是事務的參與者（參與者）
協調者向參與者釋出指令
①兩階段提交協議：
一個準備階段，一個提交階段；
存在以下為題：阻塞，單點故障和腦裂問題
保證了系統的強一致性，但是當處理狀態處於錯誤狀態，就導致了一致性和可用性不可兼得的問題了
②三階段協議
解決了阻塞（超時自動提交事務成功）和資源永遠鎖定的問題
詢問階段，準備階段，提交階段
③TCC協議（Try，Confirm，Cancel）推薦這種，以上兩種協議高併發系統中基本沒有場景用到
簡化版的三階段協議，極端情況下還是會出現不一致和腦裂的問題，好處是具有一定的自我修復能力，任何參與者可自動修復Cancel
先try，沒有問題confirm，如果出現問題，執行逆操作Cancel
（3）保證最終一致性模式
①查詢模式
任何服務操作都需要提供一個查詢介面，用來像外部輸出操作執行的狀態。服務使用方通過得知操作的執行狀態，根據不同狀態來做不同的處理操作。
為了實現查詢，每個服務操作都需要有唯一的流水號標識，例如請求流水號，訂單號等。
②補償模式
有了上面的查詢模式，可以得知具體服務操作的，如果操作處於不正常狀態，我們需要修復該操作，通過修復使整個分散式系統達到一致，為了讓系統達到一致狀態做的努力叫做補償。
補償操作分類：
1、自動恢復：程式根據發生的不一致的環境，通過繼續進行未完成的操作，或者回滾已經完成的操作，來自動達成一致狀態。
2、通知運營
3、技術運營
③非同步確保模式
通常把這類操作從主流程中摘除，通過非同步的方式進行處理，處理後把結果通過通知系統通知給使用方。最大的好處就是能夠對高併發流量進行消峰。
把要執行的非同步操作封裝後持久入庫，然後通過定時撈取未完成的任務進行補償操作來實現非同步確保模式 ，只要定時系統足夠健壯，則任何任務最終都會被成功執行。
④定期校對模式
定期校對各系統的操作狀態，如果出現不一致狀態的操作，則進行補償操作！
實現定期校對的一個關鍵就是分散式系統中需要有一個自始至終唯一的ID，生成唯一ID的兩種方法：
1、永續性：使用資料庫表自增欄位或者Sequence生成，為了提高效率，每個應用節點可以快取一個批次的ID
2、時間型：一般由機器號，業務號，時間，單節點內的自增ID組成。
多應用於金融系統中系統間一致性對賬，現金對賬，財務對賬等
⑤可靠訊息模式
1、訊息的可靠傳送（兩種）
業務模組持久化訊息傳送
和第一種類似，不過持久訊息的資料庫是獨立的，並不耦合在業務系統中
2、訊息處理器的冪等性
保證訊息一定會傳送出去，就需要有重試機制，有重試機制，訊息就一定會重複
處理重複問題的最佳方式就是保證操作的冪等性
⑥快取一致性模式
儘量使用分散式快取，而不要使用本地快取
保證弱一致性即可
快取資料一定要完整，正確
（4）超時處理模式
1、微服務的互動模式
（1）同步呼叫模式：適用於大規模，高併發的短小請求操作
（2）介面非同步呼叫模式：請求受理，返回受理結果，後面非同步返回處理結果
（3）訊息佇列非同步處理模式：利用訊息佇列作為通訊機制，服務2不需要返回處理結果給呼叫者服務1，呼叫者只是告訴服務2處理這個事件即可！
2、同步與非同步的抉擇
儘量使用非同步來替換同步操作
能用同步解決的問題，不要引入非同步
3、互動模式下超時問題的解決方案
總得來說有兩種處理方式：快速失敗和內部補償
（1）同步呼叫模式下的解決方案
①兩狀態的同步介面：成功，失敗
發現異常超時，快速返回失敗
②三狀態的同步介面：成功，失敗，處理中
發現異常超時，儘可能處理使用者發來的請求，狀態返回處理中
（2）非同步呼叫模式下的解決方案
（3）訊息佇列非同步處理模式的解決方案
（4）超時補償的原則
（5）遷移開關的設計
建議使用訂單開關：在請求建立的關聯體，例如訂單，上標記開關，標記是呼叫老系統還是新系統，而不是通過全域性或者配置的開關來判斷，避免各個節點之間的開關不同步，不一致，導致既呼叫老系統，也呼叫了新系統。
本作品採用《CC 協議》，轉載必須註明作者和本文連結