NoSQL的三大基石(CAP、BASE和最终一致性)
CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储了理论依据。这个是一切的源头。
CAP
C: Consistency 一致性
A: Availability 可用性(指的是快速获取数据)
P: Tolerance of network Partition 分区容忍性(分布式)
10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们,一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。
熊掌与鱼不可兼得也。关注的是一致性,那么您就需要处理因为系统不可用而导致的写操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好CAP理论。
作为架构师,一般有两个方向来利用CAP理论
key-value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
不同数据对于一致性的要求是不同的。举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。
CAP理论的证明:Brewer's CAP Theorem
最终一致性
一言以蔽之:过程松,结果紧,最终结果必须保持一致性
为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分:
存储系统
存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。
Process A
ProcessA主要实现从存储系统write和read操作
Process B 和ProcessC
ProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。
下面以上面的场景来描述下不同程度的一致性:
强一致性
强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值
弱一致性
假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。
最终一致性
最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。
- Causal consistency(因果一致性)
如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性。
- Read-your-writes consistency
如果Process A写入了最新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
- Session consistency
此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency.Hibernate的session提供的一致性保证就属于此种一致性。
- Monotonic read consistency
此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。
- Monotonic write consistency
此种一致性保证系统会序列化执行一个Process中的所有写操作。
BASE
说起来很有趣,BASE的英文意义是碱,而ACID是酸。真的是水火不容啊。
- Basically Availble --基本可用
- Soft-state --软状态/柔性事务
"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
- Eventual Consistency --最终一致性
最终一致性, 也是是 ACID 的最终目的。
BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性: Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步,异步。 Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时一致。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片
BASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。
I/O的五分钟法则
在 1987 年,Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持
1KB 的数据成本相当于硬盘中存据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。
随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。
原文地址: http://wangwei.cao.blog.163.com/blog/static/102362526201052444254269/
NoSQL的三大基石(CAP、BASE和最终一致性)的更多相关文章
- 大数据技术原理与应用【第五讲】NoSQL数据库:5.4 NoSQL的三大基石
NoSQL的三大基石:cap,Base,最终一致性 5.4.1 cap理论(帽子理论): consistency:一致性availability:可用性partition tolerance: ...
- 大数据 --> CAP原理和最终一致性
CAP原理和最终一致性 CAP原理和最终一致性(Eventually Consistency)
- NoSql的三大基石:CAP理论&BASE&最终一致性
关系型数据库的局限 NoSql出现在关系型数据库之后,主要是为了解决关系型数据库的短板,我们先来看看随着软件行业的发展,关系型数据库面临了哪些挑战: 1.高并发 一个最典型的就是电商网站,例如双11, ...
- [转]CAP原理与最终一致性 强一致性 透析
在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick).在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子.CAP原理中,有三个要素: 一致性 ...
- CAP原理与最终一致性 强一致性 弱一致性
CAP原理中,有三个要素: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点 ...
- 脑裂 CAP PAXOS 单元化 网络分区 最终一致性 BASE
阿里技术专家甘盘:浅谈双十一背后的支付宝LDC架构和其CAP分析 https://mp.weixin.qq.com/s/Cnzz5riMc9RH19zdjToyDg 汤波(甘盘) 技术琐话 2020- ...
- 分布式中 CAP BASE ACID 理解(转载)
概念理解(CAP,BASE, ACID) CAP CAP: Consistency, Availability, Partition-tolerance 强一致性(Consistency).系统在执 ...
- CAP理论与MongoDB一致性、可用性的一些思考
大约在五六年前,第一次接触到了当时已经是hot topic的NoSql.不过那个时候学的用的都是mysql,Nosql对于我而言还是新事物,并没有真正使用,只是不明觉厉.但是印象深刻的是这么一张图片( ...
- 分布式数据库中CAP原理(CAP+BASE)
分布式数据库中CAP原理(CAP+BASE) 传统的ACID 1)原子性(Atomicity): 事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功. 2)一致性(Con ...
随机推荐
- 使用连接来代替in和not in(使用外连接技巧)
比如:表A里面的一个字段叫做MOBILE 里面存的记录如下 : 123456781 表B里面的一个字段也叫做MOBILE里面存的记录如下 12341910 (1)我们要查询一下A和B里面都有的,以 ...
- Android开发面试经——5.常见面试官提问Android题①
版权声明:本文为寻梦-finddreams原创文章,请关注:http://blog.csdn.net/finddreams 关注finddreams博客: http://blog.csdn.net/f ...
- Maven——Maven核心概念
原文:http://www.cnblogs.com/xdp-gacl/p/4051819.html 一.Maven坐标 1.1.什么是坐标? 在平面几何中坐标(x,y)可以标识平面中唯一的一点. 1. ...
- 转:浅谈C/C++中的指针和数组(一)
再次读的时候实践了一下代码,结果和原文不一致 error C2372: 'p' : redefinition; different types of indirection 不同类型的间接寻址 /// ...
- OpenGL的gluLookAt观察变换函数详解
void gluLookAt(GLdouble eyex, GLdouble eyey, GLdouble eyez, GLdouble center ...
- phprpc 使用实例(例实没错却不能执行)函数冲突gzdecode
PHPRPC 是一个轻型的.安全的.跨网际的.跨语言的.跨平台的.跨环境的.跨域的.支持复杂对象传输的.支持引用参数传递的.支持内容输出重定向的.支持分级错误处理的.支持会话的.面向服务的高性能远程过 ...
- 【转】loading 三种实现方式
转载:http://www.eoeandroid.com/forum.php?mod=viewthread&tid=76872 一.通过动画实现 定义res/anim/loading.xml如 ...
- VC++编译MPIR 2.7.0
目录 第1章编译 2 1.1 简介 2 1.2 下载 3 1.3 解决方案 4 1.4 创建项目 5 1.5 复制文件树 6 1.6 不使用预编译头文件 8 ...
- Windows下DLL查找顺序
目录 第1章说明 2 1.1 查找顺序 2 1.1.1 检查DllCharacteristics字段 3 1.1.2 读取manifset资源 3 1.1.3 读取manifs ...
- mac svn
开启svn服务:sudo svnserve -d -r /Users/fuyi/svnserver/mycode/