本节书摘来自异步社区出版社《NoSQL权威指南》一书中的第1章，第1.6节，作者：【美】Joe Celko（乔•塞科） ，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.6 BASE
世界上现在满是巨大的分布式计算系统，如Google的BigTable、Amazon的Dynamo和Facebook的Cassandra。这里我们要提到的BASE是下面内容的简写。
基本可用（basically available）。这意味着该系统按照CAP定理保证了数据的可用性。但可以响应“失败”、“不可靠的”，因为所请求的数据是处于不一致或是正在改变的状态。你玩过魔术八球[3]吗？
**
软状态（soft state）**。系统的状态可能随着时间的推移而有所变化，所以即使在没有输入的情况下系统状态也可能会有变化，这是由于系统的目标是“最终一致性”，因此，与硬状态（这里指数据是被确认状态，也可以理解成数据状态时最终期望的状态）相对而言系统一直处在软状态。当然，系统的某部分可以存有最终数据，如像存储地理位置这样的常量表。
最终一致性（eventual consistency）。一旦系统停止接收输入，该系统最终将是一致的。这就给了我们一个可接受的短时间不一致的窗口。“可接受的短时间窗口”是一个比较含糊的说法，做非关键性的计算的数据仓库可以等待这个时间，但在线订单接收系统是务必要及时响应用户的，以保持客户满意度（短于1分钟）。还有另一个极端，实时控制系统必须立即做出响应。域名系统（DNS）是已知最常见的一种使用最终一致性的系统。域名的更新是通过协议和时间控制的缓存进行的，最终，所有的客户端将获得该更新。但更新周期已经远远超过了“瞬间”或是中心服务器更新的时间。这种需要一个全局时间戳，以便每个节点都能知道哪些数据项是最新版本。
与ACID模型相似，最终一致性模型也有很多变种。
因果一致性（causal consistency）。如果进程A已经给进程B发送了更新，随后进程B所做的后续访问都将返回更新后的值，并且新的写操作能够覆盖之前的内容。与进程A没有因果关系的进程C所做的访问会遵从正常的最终一致性规则。在早期的网络系统中这也称为伙伴系统（buddy system）。如果一个节点无法得到权威的数据源，它会问它的伙伴是否已经得到了新的数据病信任其数据。
读你所写一致性（read-your-writes consistency）。进程A，在它已更新某一数据项后，会一直访问更新后的值，而绝不会看到旧的值。这是因果一致性模型的一个特例。
会话一致性（session consistency）。这是前一个模型的一个实用版本，其中进程在会话中访问存储系统。只要会话存在，系统会保证“读你所写一致性”。如果会话因为发生故障终止，将会创建一个新会话并恢复之前的处理过程，并且保证不会重复操作。
单调读一致性（monotonic read consistency）。进程只返回最近的数据值，它永远不会返回任何之前的值。
单调写一致性（monotonic write consistency）。在这种情况下，系统保证数据通过同一个进程顺序地写入。不保证这个级别一致性的系统是很难开发的。可以把它认为是在网络中某个节点的本地队列。
上面这些特性是可以组合的。例如，单调读一致性结合会话级一致性就是其中一种组合。从应用角度来看，单调读一致性和读你所写一致性是最终一致性系统中最需要考虑的，但也并非总是必需的。这两个特性使开发人员可以更简单地构建应用程序，同时允许存储系统在一致性问题上更加宽松，并提供更高的可用性。
最终一致性往往采用同步或异步复制技术，已经成为RDBMS产品中备份系统的一部分。在同步模式下，复制更新是事务的一部分。在异步模式下，由于日志传输，更新可能会被延迟。如果数据库在日志传送前崩溃，备份数据可能是过时的或不一致的。基本上，不一致性的窗口取决于日志传送的频率。
