CAP VS BASE
一致性
强一致性
保证手段：单机落磁盘、数据库事务、分布式事务等
弱一致性
可能丢失一定的数据：异步复制、PageCache的write back
最终一致性
带TTL的缓存
HOW:
1.规避分布式事务业务整合
业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务A、B、C整合为一个服务D给业务，这个服务 D再通过转换为本地事务的方式，比如服务D包含本地服务和服务E ， 而服务E是本地服务A~C的整合。
优点：解决（规避）了分布式事务。
缺点：显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。
由于这个方法存在明显缺点，通常不建议使用。
2.经典方案-eBay模式
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
消息日志方案的核心是保证服务接口的幂等性。
考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。
