BASE

BASE思想解决了CAP提出的分布式系统的一致性和可用性不可兼得的问题。

BASE是“碱”的意思，ACID是“酸”的意思，基于这两个名词提出了“酸碱平衡”的理论，简单来说就是在不同的场景下，可以分别利用 ACID和BASE来解决分布式服务化系统的一致性问题。

BASE思想与ACID原理截然不同，它满足CAP原理，通过牺牲强一致性获得可用性，一般应用于服务化系统的应用层或者大数据处理系统中，通过达到最终一致性来尽量满足业务的绝大多数需求。

BASE模型包含如下三个元素。 BA：Basically Available，基本可用。 S：Soft State，软状态，状态可以在一段时间内不同步。 E：Eventually Consistent，最终一致，在一定的时间窗口内，最终数据达成一致即可。

软状态是实现BASE思想的方法，基本可用和最终一致是目标。以 BASE思想实现的系统由于不保证强一致性，所以系统在处理请求的过程中可以存在短暂的不一致，在短暂的不一致的时间窗口内，请求处理处于临时状态中，系统在进行每步操作时，通过记录每个临时状态，在系统出现故障时可以从这些中间状态继续处理未完成的请求或者退回到原始状态，最终达到一致状态。

以转账为例，我们将用户A向用户B转账分成4个阶段：第1个阶段，用户A准备转账；第2个阶段，从用户A账户扣减余额；第3个阶段，对用户B增加余额；第4个阶段，完成转账。系统需要记录操作过程中每个步骤的状态，一旦系统出现故障，系统便能够自动发现没有完成的任务，然后根据任务所处的状态继续执行任务，最终彻底完成任务，资金从用户A的账户转账到用户B的账户，达到最终的一致状态。

在实际应用中，上面这个过程通常是通过持久化执行任务的状态和环境信息，一旦出现问题，则定时任务会捞取未执行完的任务，继续执行未执行完的任务，直到执行完成，或者取消已经完成的部分操作并回到原始状态。这种方法在任务完成每个阶段时，都要更新数据库中任务的状态，这在大规模、高并发系统中不会有太好的性能，一种更好的办法是用Write-Ahead Log（写前日志），这和数据库的Bin Log（操作日志）相似，在进行每个操作步骤时，都先写入日志，如果操作遇到问题而停止，则可以读取日志并按照步骤进行恢复，继续执行未完成的工作，最后达到一致的状态。写前日志可以利用机械硬盘的追加写来达到较好的性能，然而这是一种专业化的实现方式，多数业务系统还是使用数据库记录的字段来记录任务的执行状态，也就是记录中间的“软状态”。一个任务的状态流转一般可以通过数据库的行级锁来实现，这比使用写前日志实现更简单、快速。

有了BASE思想作为基础，我们对复杂的分布式事务进行拆解，对其中的每个步骤都记录其状态，有问题时可以根据记录的状态来继续执行任务，达到最终一致。

解决一致性问题的三条实践经验。 使用向上扩展（强悍的硬件）并运行专业的关系型数据库（例如 Oracle、DB2和MySQL），能够保证强一致性，能用向上扩展解决的问题都不是问题。如果向上扩展的成本很高，则可以对廉价硬件运行的开源关系型数据库（例如MySQL）进行水平伸缩和分片，将相关数据分到数据库的同一个片上，仍然能够使用关系型数据库保证事务。如果业务规则限制，无法将相关数据分到同一个分片上，就需要实现最终一致性，在记录事务的软状态（中间状态、临时状态）时若出现不一致，则可以通过系统自动化或者人工干预来修复不一致的问题。