本节书摘来自异步社区出版社《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产品中备份系统的一部分。在同步模式下,复制更新是事务的一部分。在异步模式下,由于日志传输,更新可能会被延迟。如果数据库在日志传送前崩溃,备份数据可能是过时的或不一致的。基本上,不一致性的窗口取决于日志传送的频率。
还没有评论,来说两句吧...