ACID 即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）

• 原子性：整个事务中的所有操作，要么全部完成，要么全部失败，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
• 隔离性：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时中间某一时刻的数据。两个事务不会发生交互。
• 持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。

CAP 理论——在分布式的服务架构中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）

BASE

• Basic Availability：基本可用。这意味着，系统可以出现暂时不可用的状态，而后面会快速恢复。
• Soft-state：软状态。它是我们前面的“有状态”和“无状态”的服务的一种中间状态。也就是说，为了提高性能，我们可以让服务暂时保存一些状态或数据，这些状态和数据不是强一致性的。
• Eventual Consistency：最终一致性，系统在一个短暂的时间段内是不一致的，但最终整个系统看到的数据是一致的。

业务补偿主要做两件事。

• 努力地把一个业务流程执行完成。
• 如果执行不下去，需要启动补偿机制，回滚业务流程。

事务补偿机制TCC（Try、Confirm、Cancel），是由2PC（两阶段提交）演变而来在业务层面去解决一致性问题的一种方案。其精髓在于定于业务执行逻辑的时候，同时实现一个抵消（补偿）正向逻辑的cancel操作，以便在异常情况下对原有操作进行回滚。其主要操作如下：

• Try操作做业务检查及资源预留--一般用户框架对外暴露服务
• Confirm做业务确认操作--真正执行的逻辑操作，一般认为Try成功Confirm一定成功
• Cancel实现一个与Try相反的操作既回滚操作--TCC的精髓，为业务操作定义一个补偿的操作 （对于不了解TCC的同学可以参考下，了解大致背景后再看晧哥的文章会有更深的体会。基本可以当做TCC的最佳实践去读。）