BASE（Basically Available, Soft State, Eventually Consistent）是一種分佈式系統設計原則，它與傳統的ACID（Atomicity, Consistency, Isolation, Durability）模型相對應。在構建大規模、高可用性的分佈式系統時，BASE的設計原則被廣泛採用。
BASE所強調的最終一致性，是指系統中的數據最終會達到一致的狀態，儘管在此過程中可能存在一定的時間窗口內的數據不一致情況。與強一致性模型不同，BASE允許系統中的數據在不同節點之間存在短暫的不一致狀態，但會通過自動的異步機制逐漸實現數據的同步和一致性。這種方式在一定程度上提高了系統的可用性和性能，並允許系統在面對網絡延遲、故障或分區等複雜的分佈式環境中仍能正常運行。
BASE原理舉例分析
AP設計的優勢在於它更加關注用戶體驗而不是嚴格的數據一致性。具體地說，當訂單創建時，AP設計允許系統立即將訂單創建成功的結果返回給用戶，而無需等待短信發送完成。這種方式可以顯著提高用戶的響應速度和體驗，因爲用戶無需等待額外的時間來完成訂單創建流程。儘管在此過程中，短信發送的結果可能會稍後實現一致性，但對於用戶來說，這並不是首要關注的，重要的是快速地確認訂單提交成功。因此，AP設計非常適合那些對數據一致性要求不是特別高、但追求快速響應和卓越用戶體驗的應用場景。
如何保證短信數據最終與訂單數據一致，這時候BASE原則就可以派上用場
基本可用（Basically Available）：系統保證在出現故障或異常情況下仍然能夠保持基本的可用性，即系統仍然能正常響應用戶的請求。這意味着系統會盡量避免完全不可用的狀態，而是通過限制某些功能或降低某些要求來保證系統的可用性。
體現：創建訂單後返回，不等待短信發送結果,短信是否發送成功對用戶影響不大
軟狀態（Soft State）：系統中的數據在不同節點之間可能存在短暫的不一致狀態，即系統中的數據副本在經過一段時間後會達到一致。這個過程中，系統容許存在一定的數據不一致，但最終會收斂到一致的狀態。這與強一致性模型不同，強調了允許數據的臨時不一致性。
體現：在訂單創建後，短信記錄未發送成功前就屬於軟狀態
最終一致性（Eventually Consistent）：系統最終會達到一致的狀態。即使在數據更新的過程中存在一定的時間窗口，不同節點上的數據可能會有所不同，但經過一段時間後，系統會自動進行數據同步，最終實現所有節點上的數據一致性。
體現：過一段時間後讓短信發送成功與訂單狀態一致
有哪些技術手段可以保證最終一致性?
重試（MQ重試機制，接口調用的重試機制）
數據校對方式
人工介入
凌晨跑的報表出錯了，早上客服發現，手動再跑一次