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重试机制，接口调用的重试机制）
数据校对方式
人工介入
凌晨跑的报表出错了，早上客服发现，手动再跑一次