强一致性的最佳保证最好是在底层完成。或是像Stateful 的 Sticky Session 那样在一台机器上完成。大多数业务最终一致性就好。
一、ACID 和 BASE区别
ACID 保证了数据库的一致性(银行转账)
分布式系统，尤其微服务，这样的方式是很难高性能。因为CAP 理论和提高性能，出现了 ACID 的一个变种 BASE。
Basic Availability：基本可用。暂时不可用的状态，后面会快速恢复。
Soft-state：软状态。“有状态”和“无状态”的服务的一种中间状态。为了提高性能，让服务暂时保存一些状态或数据，这些状态和数据不是强一致性的。
Eventual Consistency：最终一致性，短暂的时间段内不一致，最终整个系统看到的数据是一致的。
二、网上卖书的场景：
ACID：买同一本书的过程中，每个用户的购买请求都需要把库存锁住，等减完库存后，把锁释放出来，后续的人才能进行购买。同一时间不可能有多个用户下单，有排队的情况，不可能做出性能比较高的系统来。
BASE：可以同时下单，不需要去真正地分配库存，异步且批量地处理订单。下单没有真正去减库存，有可能会有超卖的情况。异步地处理订单时，发现库存没有了，于是才会告诉用户你没有购买成功。
BASE 这种玩法，其实就是亚马逊的玩法，因为要根据用户的地址去不同的仓库查看库存，这个操作非常耗时，所以，不想做成异步的都不行。
系统收到你的订单了，然后一会儿你会收到你的订单被确认的邮件，这时候才是真正地分配了库存。某些时候，你先收到了下单的邮件，过一会又收到了没有库存的致歉的邮件。
三、业务补偿
业务补偿：首先做成幂等性的，一个事务失败了或是超时了，不断地重试，努力地达到最终我们想要的状态。如果达到，状态恢复到之前。如果有变化的请求，启动整个事务的业务更新机制。
比如：要找很多方协调很多事，每一件事都要成功，否则整件事就做不到。
可以并行地做这些事，而如果某个事有变化，其它的事都会跟着出现一些变化。
1.业务补偿机制需要做到下面这几点：
（1）起始状态定义：要达到什么样的状态（比如：请假、机票、酒店这三个都必须成功，租车是可选的），如果条件不满足，要回退到哪一个状态。是整个业务的
（2）状态拟合：当整条业务跑起来的时候，我们可以串行或并行地做这些事。对于旅游订票是可以并行的，但是对于网购流程（下单、支付、送货）是不能并行的。总之，我们的系统需要努力地通过一系列的操作达到一个我们想要的状态。如果达不到，就需要通过补偿机制回滚到之前的状态。
（3）修改事务：对于已经完成的事务进行整体修改。
纯技术的世界里也有这样的事。比如，线上运维系统进行水平扩展，先找到相应的机器，然后初始化环境，再部署上应用，再做相应的健康检查，最后接入流量。这一系列的动作都要完全成功，所以，我们的部署系统就需要管理好整个过程和相关的运行状态。
2.业务补偿的设计重点
（1）支持幂等性，在上游有重试机制，因为要把一个业务流程执行完成，
（2）工作流引擎（高可用和稳定的），维护和监控整个过程的状态，不要把这些状态放到不同的组件中。把需求告诉它，帮我们搞定所有的事。如果有问题，也会回滚和补偿的。
（3）设计业务正向流程的时候，也要设计业务的反向补偿流程.补偿的业务逻辑和流程不一定非得是严格反向操作。有时候可以并行，有时候，可能会更简单。
（4）业务补偿的业务逻辑是强业务相关的，很难通用的。
（5）下层的业务方最好提供短期的资源预留机制。就像电商中的把货品的库存预先占住等待用户在 15 分钟内支付。如果没有收到用户的支付，则释放库存。然后回滚到之前的下单操作，等待用户重新下单。
