BASE 最终一致性理论 – 西门飞冰的博客

什么是BASE最终一致性

BASE 最终一致性是对CAP理论中一致性（C）和可用性（A）进行权衡的结果，起到承上启下的作用。其核心思想是无法做到强一致性，但每个应用都可以根据自身的特点，采用适当方式达到最终一致性。

举个例子：

CP：表现为订单创建后一直等待短信发送后才返回结果。强一致性表现，用户体验差。

AP：表现为订单创建后无需等待短信是否发送直接将订单创建成功结果返回，用户体验好，那么短信数据怎么办？BASE（最终一致性）设计就派上用场了。

Basically Available（基本可用）

Soft state（软状态）

Eventually consistent（最终一致性）

基本可用：就是快速实现用户的基本价值与诉求“创建订单”后立即返回就是基本可用的体现

软状态：代表了在业务操作没有最终完成前的中间状态在订单创建后，短信记录未发送成功前就属于软状态

最终一致性：代表通过技术手段过一段时间后让数据保持完整的状态

注意：最终一致性不能100%保证数据的最终一致，最多可以保障99.99999%的一致性，这也是为什么金融场景，冒着宁愿降低用户体验，也要选择CP架构的原因。

以订单系统和短信系统为例：订单系统处理完成后，立即返回响应，把发送短信的消息放到MQ队列里，再由短信服务进行订阅，如果中间消息订阅过程中或者发送过程中，出现各种各样的问题，那么MQ都会通过重试的方式，多次重新发送，来尽可能的保证消息被短信服务来处理。

自己开发一个数据校对程序，定时运行检查，看看有没有哪些数据出现了不匹配或者丢数的情况，比如刚才的场景就可以自己写一个校对程序，对指定时间范围的的订单数据和短信数据进行比对，如果完全能匹配上说明我们所有业务处理成功了，否则就需要看哪个短信没有发送成功，并通过校对程序进行补发。

人工介入属于比较极端的情况，适用于觉得计算机处理不靠谱的场景使用。

难忘的回忆：某次线上neo4j数据库数据被误删除，因为neo4j不支持增量数据备份，所以我们只有指定时间段的全量数据备份。全量数据恢复后，备份和故障时间段丢失的数据，只能运维通过nginx的请求日志，一条条分析，录入。