三个部分：
1、基本可用（Base Availability）。
基本可用就意味着可以容许系统有短暂的不可用状态，只要能快速恢复就可以。
2、软状态（Soft-state）。
软状态是跟持久状态相对的，也就意味着系统可以处于一种中间状态，既不是事务执行前的状态，也不是事务成功执行后的状态，这种状态会导致系统的不一致性，但是这种不一致性是短暂的，最终是要回归到一致性的。
3、最终一致性（Eventual Consistency）。
最终一致性跟强一致性相对，也就意味着系统只要能在可接受的时间范围内达到一致性即可。
BASE理论容许系统出现短暂性的问题的，无论是短暂的不可用还是短暂的不一致状态，只要能够在一定时间范围内最终达到可用或者一致状态即可。
补偿机制
既然BASE理论容许系统处于短暂的不可用和不一致的状态，那么在设计的时候怎么去保证最终的可用和一致状态呢？这就需要引入补偿机制。
现在的系统往往都微服务化了，所以要完成某一个业务流程往往涉及到很多个服务，甚至涉及很多个外部的系统，外部系统的可用性不是我们能够保证的，我们在设计实现流程时能够做的就是当在调用某个三方系统失败时，后续的流程应该怎么去设计。这就需要工作流编排的能力。工作流的编排完全是基于业务的，需要根据业务的实际情况来进行流程的转换。
举个例子来说。如果去某个地方旅游，来回机票、酒店都定好了，但是旅游地的短途交通还没有预定成功，这也不会使得我们放弃这次旅游，因为旅游地的短途交通这个事情我们确认可以解决的。这个就说明当整个业务流程中的非关键操作失败后，业务流程可以正常执行。但是如果是回程机票没有定好，那我们可能就会试着再重试去预定，如果实在预定不到，那我们就会取消这次旅游，并且就会去启动取消去程的机票和预定的酒店。这个就说明当整个业务流程中的关键操作失败后，业务流程必须实行回滚操作。
补偿机制的设计有几个关键点需要考虑：
- 1、要使得一个业务流程能够执行完成，必须得保证流程涉及的所有的服务都必须是幂等性的，并且在整个流程的执行过程中需要有重试机制。
- 2、整个补偿机制的工作流是状态驱动的，所以需要时刻关注业务流程执行过程中的状态，当某个状态出现时需要有效地驱动工作流引擎中的下一个动作，继续执行或者进行回滚或者补偿动作。
- 3、当业务流程执行失败后，需要启动补偿的流程，这个补偿流程不一定完成是业务流程的反向操作，可以根据实际的情况来制定补偿的操作，目标就是补偿流程的启动要么就是保证业务流程执行成功，要么就是保证回滚到业务流程执行前的状态。
- 4、有些业务补偿操作不一定需要即时执行，在保证关键的业务操作执行成功的情况下，对于一些非关键的业务操作，可以推迟或者降低优先级执行。