ACID 和 BASE (& CAP)

(优化版) 有必要先说一下 ACID 和 BASE 的差别。传统关系型数据库系统的事务都有 ACID 属性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。下面我逐一做下解释：原子性：整个事务中的所有操作，要么全部完成，要么全部失败，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。隔离性：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时中间某一时刻的数据。两个事务不会发生交互。持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。

事务的 ACID 属性保证了数据库的一致性，比如银行系统中，转账就是一个事务，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，是不可拆分的原子操作，从而保证了整个系统中的总金额没有变化。

然而，这对于我们的分布式系统来说，尤其是微服务来说，这样的方式是很难满足高性能要求的。我们都很熟悉 CAP 理论——在分布式的服务架构中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance），在现实中不能都满足，最多只能满足其中两个。

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

可以看到，BASE 系统是允许或是容忍系统出现暂时性问题的，这样一来，我们的系统就能更有弹力。因为我们知道，在分布式系统的世界里，故障是不可避免的，我们能做的就是把故障处理当成功能写入代码中，这就是 Design for Failure。

不同数据库选择的特性:
可以看到像大部分关系型数据库采用的是CA的特性,即Consistency、Availability.

常见的非关系型数据库产品包括：
CP:
MongoDB：面向文档的数据库，使用JSON-like格式存储数据。
Redis：内存键值存储系统，也支持数据持久化，并且提供了丰富的数据结构支持。
HBase：基于Hadoop的大规模分布式列式存储系统，适用于大数据分析。
AP:
Cassandra：由Facebook开发，专为分布式环境设计的列族数据库。