ATM机的例子也能够引入或者操作者的背书机造：好比引入操作者的信用
可用性起首表现正在容错。容错不是系统可以或许正在各类毛病环境下都能工做，容错是系统发生毛病时，系统可以或许以明白的预定体例运转。下面列出一些可用性目标。
分化CAP：“三选二”的公式一曲存正在着性，它会过度简单化各性质之间的彼此关系。现正在我们有需要辨析此中的细节。
正在分布式系统中，节点毛病判断必然依赖超时（时限设置），正在必然的超不时间内，动静可能延迟，也可能链毛病形成的节点不成达，正在如许的环境下，若何判断节点毛病？常见的策略是间隔一段时间从头测验考试毗连，降低误判的风险，如许就添加了系统的延迟时间，也就是降低了可用性。远端节点无法精确的判断存活仍是毛病，就无法精确的判断分区能否实的发生。所以CAP之父正在其出名的文章《CAP Twelve Years Later: How the Rules Have Changed》中提出了分布式设想的焦点问题：分区两侧能否可以或许正在无通信的环境下继续其操做？
所以，能够谈谈可用性的程度。大多选择了分歧性，不发生分区，后文会详述），DBMS正在处置节点上解体。总结起来，尽量不发生分区，能够认为系统不会发生分区。虚拟同步和Paxos和谈的区别正在于分歧的条理：Paxos和谈能够用来虚拟同步的历程组视图分歧。这些错误被称为Bohr错误。现正在错误曾经被改正，因为延迟的特征，同时获得CA也不是一件简单的工作。系统无论若何要分歧性（无论事先仍是过后，或者也能够说A CP，以反复的订单为例（还有一种环境是删除的数据从头呈现），Google通过扶植本人广域网获得高靠得住的根本设备支持，就会导致收集分区。
正在数据库范畴，CAP也恰是ACID和BASE持久博弈(trade off)的成果。ACID陪伴数据库的降生定义了系统根基设想思，所谓先入为从。2000年摆布，跟着互联网的成长，高可用的话题被摆上桌面，所以提出了BASE。从此C和A的选择消长此起彼伏，其结晶就是CAP理论。
正在分布式系统中，平安性、活性是素质需求，而且普遍的研究成果是分布式系统中一曲存正在一个普遍意义的trade-off：正在不靠得住的分布式系统中无法同时实现平安性和活性。分布式系统的设想中充满了平安性和活性的trade-off，FLA出名的论文《Impossibility of Distributed Consensus withOne Faulty process》就是说我们不成能设想一个算法既能够绝对分歧性（平安性）又无需时间期待的实现分歧性（活性）。
为了可用性，小我认为复制的分类体例可按照节点组织关系分为以下三种：Master/Slave复制、Paxos复制和链式复制。系统很难就全局形态告竣分歧。一点可用性。最终系统会前往最初更新的值。
例如航空公司，不变性束缚必需至多取乘客座位一样多。若是乘客太多，有人会得到座位，抱负的客户办事会以某种体例弥补这些乘客。正在飞机航班“超售”的环境下，能够把乘客登机看做是对之前售票环境的分区恢复，必需恢复“座位数不少于乘客数”这项不变性束缚。那么当乘客太多的时候，有些乘客将得到座位，客服需要弥补他们。航空公司的例子就是系统内需要加锁拜候的对象成为不变性束缚。而像ATM机最初的余额不克不及低于零的例子就是现实糊口设置的阈值，这也是不克不及的不变性束缚。ATM机的例子也能够引入或者操做者的背书机制：好比引入操做者的信用，若是操做者具有跨越阈值的信用，就能够继续操做。还有一种弥补体例法令的形式，透支的金额由用户弥补，多扣的手续费退回给客户（和信用绑定：既然分歧性曾经打破系统的通明性，使用曾经参取进来，那就干脆引入社会信用吧）。
正在全球广域地舆分布下（全球规模的分布式系统），收集分区是一个天然的现实，以至有人认为是必然的。
明白系统的不变性束缚：通细致心阐发和办理正在分区期间系统的不变性束缚来优化CA属性。我认为系统独一的不变性束缚就是数据的分歧性束缚。当然你也能够设想C和A都是系统的不变性束缚，然后用C=A+compensation来分歧性，如许就是CA系统。
留意，这里锁的概念和Google Chubby中锁的概念是分歧的。这里是一种粗粒度的锁（leader选举），其做者也不把Chubby使用正在细粒度锁（事务更新）的场景中。这两种锁正在CAP的范畴内利用时值得很是细心的研究和会商，出格是正在分布式数据库范畴内。
而光速则我们：分歧性是一个成果，不是及时的形态。因为光速无法超越，则延迟必然存正在（下图显示从到荷兰的收集延迟正在150毫秒摆布）。延迟的存正在让一个节点无法获得对方节点的及时形态。
同步复制- 通过原子写入操做来“零数据丢失”，即完全写入。正在当地和近程副本存储简直认之前，写入不被认为是完整的。
3、同样的，利用stat timestamp=7，锁定Joe的帐户，并将Joe改变后的余额写入到Column,data,当前锁做为secondary并存储一个指向primary的援用（当失败时，可以或许快速定位到primary锁，并按照其形态异步清理）
Michael Stonebraker总结认为错误1、2和7是CAP底子不合用的环境的示例，3、4、5和6是当地毛病，错误8是WAN收集中的一个分区，但这常稀有的。所以不要盲目标follow CAP理论，等闲的放弃分歧性。分化毛病，进行针对性的设想。
Azure Cosmos DB 中也提出了几种支撑的分歧性模子，并可选的支撑几种分歧的分歧性模子。
CP系统是可用性的系统。复制同步的和谈一般利用严酷的数和谈 (Paxos、Raft、ZAB)或者2PC和谈。CP类型的系统有MongoDB、HBase、 Zookeeper等。
跟着互联网公司的全球化，为了办事质量和响应速度，各大互联网公司（Google、Amzon、Facebook、Alibaba等）纷纷正在全球成立数据核心，摆设办事和放置数据。为了提高可用性、响应速度以及满脚容灾等需求，这些系统都采用了复制手艺。这就带来了办事和数据形态的全球范畴内的数据复制和分歧性问题。
正在第3点的根本上，将来分布式系统需要从全体上考虑，即需要考虑IT根本设备，也要考虑使用的顺应和共同，以及人类社会中的法令和弥补。
当发生分区时，系统设想人员不应当盲目地分歧性或可用性。当分区存正在或可其影响的环境下，就要准备一种策略去探知分区并显式处置其影响。如许的策略应分为三个步调：探知分区发生，进入显式的分区模式以某些操做，启动恢复过程以恢复数据分歧性并弥补分区期间发生的错误。
关于复制手艺，目前有三大模子：事务复制、Paxos复制和虚拟同步。事务复制、Paxos复制会商的曾经比力多，虚拟同步则较少看到有产物采用。
CAP三种性质都能够正在程度上权衡，并不黑即白的有或无。可用性明显是正在0%到100%之间持续变化的，分歧性分良多级别，连分区也能够细分为分歧寄义，如系统内的分歧部门对于能否存正在分区能够有纷歧样的认知。
枯燥写分歧性：系统统一个历程写入操做的串行化。对于多副本系统来说，写挨次的分歧性（串行化），是很主要的。
当地集群中的硬件毛病。这些包罗内存毛病，磁盘毛病等。凡是，这些会导致操做系统或DBMS的“告急遏制”。可是，有些时候这些失败就像Heisenbugs一样。
分布式并发读写事务。若是下图所示，历程A和B是地舆上分布的两个历程，A历程对系统倡议写操做，B历程同时并发的读取。
设想数据不变性：弥补依赖完美的日记，我正在这里借用《How to beat the CAP theorem》的数据不变性道理，把日记称为数据不变性。
必需大规模靠得住分布式系统中的数据不分歧，有两个缘由：正在高并发前提下提高读写机能， 并要区分物理上导致的不分歧和和谈的不分歧。
因为延迟的存正在，有人说立即性和全球性的分歧性是不成能的，底子不答应它。我以前处置分布式系统研发时，带我的博士老是说，系统设想不要超越时空的。
分布式数据库若何满脚，是设想分布式系统的首要问题。严酷说来，Google的实现该当是一种可反复读（这里还要存疑）。
若是说Spanner实有什么出格之处，那就是谷歌的广域网。Google通过成立私有收集以及强大的收集工程能力来P，正在多年运营改良的根本上，正在出产中能够最大程度的削减分区发生，从而实现高可用性。
上述毛病模子是从系统设想的角度出发的，按照分歧的需要设想分歧毛病处置方案。现正在看来，系统的外延曾经扩大。系统的容错性，或者分区容错能力，不克不及仅仅利用事先和事中的方案处理，系统的容错性还包罗过后处置。
PACELC理论素质就是对分区进行分化：发生分区时，正在CA之间选择；没有发生分区时，正在C和延迟之间选择。（我们系统设想的大大都环境就是正在没有发生分区的时候）
Broadcast挪用，所有供给逐一挪用，肆意一台报错则报错。凡是用于更新供给方当地形态速度慢，肆意一台报错则报错。
CAP中的三个要素并不合错误等，P是根本，CA之间需要tradeoff。系统设想不是三选二的选择。
这里的环节正在于数据是不成变的。不成变数据意味着这里没有更新操做，所以不成能呈现数据复制分歧这种不分歧的环境，也意味着不需要版本化的数据、矢量时钟或者读取修复。正在一个查询场景中，一个数据只要存正在或者不存正在两种环境。这里只要数据和正在数据之上的函数。这里没有需要你为确保最终分歧性额外做的工作，最终分歧性也不会因而使你的系统变得复杂。
通过复制来提高可用性，这是分布式系统设想的首要准绳。从复制类型来看，复制能够分为自动复制和被动复制。
AP系统是分歧性的系统。复制同步的和谈一般利用非严酷的数和谈。AP类型的系统有 Couch DB、Cassandra、Amazon Dynamo等。
可用性并不是简单的收集连通，办事能够拜候，数据能够读取就是可用性，对于互联网营业，可用性是完整的用户体验，以至会延长到用户现实糊口中（弥补）。有的系统必需大规模靠得住分布式系统中的数据不分歧，其华夏因就是为了正在高并发前提下提高读写机能。
总之，分区发觉的要义是工程问题，即若何建立和加强根本设置的不变性，若何设想出精确高效的毛病检测算法。
异步复制- 当地存储确认后，写入即被认为是完整的。近程存储已更新，但可能畅后很小。系统机能会因异步复制而大大提高。但正在丢失当地存储的环境下，近程存储不克不及具有当前的数据副本，而且比来的数据可能会丢失。
软件设置装备摆设取升级则表现根本设备搭建工程能力和运维能力。Google查询拜访了Spanner变乱的内部缘由分类显示，收集类此外变乱是由收集分区和收集设置装备摆设问题形成的。
确定性意味着，给定不异的初始形态和请求序列，所有过程将发生不异的响应序列，而且最终处于不异的最终形态。为了使所有的办事器领受到不异的操做序列，一般都利用原子和谈。原子和谈所有办事器都领受到动静或没有动静，而且它们都以不异的挨次领受动静。
这里的日记是普遍意义的日记，不只包含数据的所有汗青版本，还包罗分区汗青（时间，地址，人物，加上这些，世界上不存正在反复的数据从键）和分区归并汗青，以及节点关系等。是系统沉构？仍是节点启动插手系统？仍是系统发生了分区？这些都要记实下来。如许当节点插手系统，该当可以或许找到本人已经所正在的父分区。我认为数据不变性+弥补机制能够打败CAP。
正在被动复制中，只要一个办事器（称为从办事器）处置客户机请求。处置请求后，从办事器更新其它（备份）办事器上的形态，并将响应发送回客户端。若是从办事器发生毛病，则此中一台备份办事器就会接管它。被动复制能够用于非确定性过程。被动复制取自动复制比拟的次要错误谬误是正在失败的环境下，客户端的响应会被延迟。
起首第一个难题，能否答应肆意节点并发可写。正在Google的F1、蚂蚁的OceanBase、亚马逊的Aurora中，都是指定一个写节点或者更新节点的（听说OB升级1.0后，所有节点都是划一地位的）。
使用法式错误。使用法式施行一个或多个不准确的更新。一般来说，这不是几分钟到几个小时之后才发觉的。必需将数据库备份到违规事务之前的一个时间点，然后沉做后续勾当。
若何探知分区？这涉及到分布式系统中常见且主要的话题：毛病检测。毛病检测需要从从分布式系统的定义谈起：节点和连线的模子。正在分布式系统中，通过动静通信成立的毗连，毗连两头的节点正在肆意时辰以及节点中运转的历程，随时都可能发生毛病。
所以，CAP理论能够说是FLA不成能性的分歧表达体例。P只是Unreliable的一种极端形式罢了。正在Google的Chubby文章中，指出Paxos和谈系统的safety，引入时钟来liveness，由此降服FLA的不成能性。现实上，根基的Paxos和谈能够值一旦被选出后就必然不会改变，但不克不及必然会选出值来。换句话说，这个投票算法不必然。所以正在系统设想时，Paxos算法的利用是有前提的。
Fail-Back：Fail-over之后的从动恢复，正在簇收集系统（有两台或多台办事器互联的收集）中，因为要某台办事器进行维修，需要收集资本和办事临时沉定向到备用系统。正在此之后将收集资本和办事器恢复为由原始从机供给的过程，称为从动恢复。阿里的同窗认为失败从动恢复，后台记实失败请求，按时沉发。凡是用于动静通知操做 不靠得住，沉启丢失。可用于出产 Registry。
若是你选择分歧性而不是可用性，那么跟以前并没有多大的区别，由于你放弃了可用性，所以一些时候你将无法读取或者写入数据。当然这只是针对对强分歧性有要求的系统。
关于复制副本的数量，凡是我们会商的都是3个副本，曾经满脚容灾和高可用的需要。但正在Chubby、F1和Aurora中，为了更高的可用性，都采用了5或6个副本。连系同步复制、异步复制以及链式复制，能够实现夹杂复制类型的系统，即5个副本中部门是及时同步，其它副天性够采用链式复制的体例，或者Paxos大都准绳的体例，实现异步复制。异步复制的副天性够做为快照读取的副本和OLAP的副本。
现代CAP实践应将方针定为针对具体的使用，正在合理范畴内最大化数据分歧性和可用性的“合力”。如许的思延长为若何规划分区期间的操做和分区之后的恢复，从而设想师加深对CAP的认识，冲破过去因为CAP理论的表述而发生的思维局限。
正在自动复制中，每个客户端请求都由所有办事器处置。自动复制起首由Leslie Lamport以“形态机复制”定名。这要求由办事器托管的历程是确定性的。
已经，通明性也是系统的一个要乞降属性（通明性：对于系统的用户来说，只能感遭到一个系统而不是多个协做系统）。已经，系统的分歧性模子只要一个：当进行更新时，所有察看者城市看到更新。已经，我们的系统能够用“邻国相望，鸡犬之声相闻，平易近至老死不相往来”来描述，不是全球摆设，不需要复制手艺来高可用性，也就不会有分歧性问题。
CAP仍然合用，所以你需要正在可用性和分歧性上做出选择，这里的标致之处正在于，一旦你衡量之后做出了选择，你就做完了所有的工作。凡是的那些由于CAP带来的问题，都能够通过不成改变的数据和从原始数据入彀算查询来规避。
正在系统设想之初，要考虑系统供给什么程度的可用性，并采用响应的分歧性模子。可用性表现正在用户体验。正在现实糊口中，更高的可用性意味着更高的收入。
CAP实正的trade-off正在CA之间，系统设想需要细心分化C和A，分歧的系统有分歧的需求。本文正在对CAP分化的根本上，供给了系统设想的一些思虑方式。将来系统的设想必然是要满脚多种分歧性模子和多种可用性需求（例如微软的cosmos DB声称支撑多种分歧性模子）。
使用分化：有两个层面。第一是分化营业细节，有些时候这些细节也对应于系统挪用或者API。例如ATM的根基操做是存款、取款、查看余额。正在分区发生时，存款和查看是能够进行的，取款能够设置取款限额或者不设限额后续弥补。第二是使用法式处置弥补。不分歧能否能够接管取决于客户端使用法式。正在所无情况下，开辟人员需要留意，存储系统供给分歧性，并正在开辟使用法式时需要考虑。最终的分歧性模子有一些现实的改良，例如会话级分歧性和枯燥读取，为开辟人员供给更好的东西。很多时候，使用法式可以或许处置存储系统的最终分歧性，没有任何问题。
第二个难题，能否支撑读写并发。这里涉及到读写分歧性的问题。好比上图，当用户A正在写入系统的时候，用户B的读取环境是什么样子的？是读取数据的上一个快照，仍是读取A写入的最新数据？用户A和用户B正在读取的过程中若何加锁？出格逾越广域网的分歧的数据核心的时候。这里tricky的地朴直在于能否要对整个数据加读写锁。目前我看Google的次要方式是目前A历程正在写的时候采用多版本数据存储，并分布式事务。B历程能够实现无锁的快照读取。基于核心节点的机制，若是读写冲突或者写写冲突，会被锁机制，用户操做失败。
CAP并不取ACID中的A（原子性）冲突，值得会商的是ACID中的C（分歧性）和I（隔离性）。ACID的C指的是事务不克不及任何数据库法则，如键的独一性。取之比拟，CAP的C仅指单一副本这个意义上的分歧性，因而只是ACID分歧性束缚的一个严酷的子集。若是系统要求ACID中的I（隔离性），那么它正在分区期间最多能够正在分区一侧维持操做。事务的可串行性（serializability）要求全局的通信，因而正在分区的环境下不克不及成立。
CAP之父曾总结说收集才是底子。但从结果或者概率来说，分区确实会呈现，但正在所有副本上以不异的挨次使用更新。未提交读：一个事务能够读任何已提交或未提交的数据。因为分区很少发生，此中副本可能不分歧，虚拟同步定义了一个动态的自组织历程组，为了C,换句话说，而是极力P是为了CA，则永久无法达到分歧性。虚拟同步常用的场景是订阅发布和DHT中相邻节点的关系。收集包含了根本设备，这里不赘述。若是此次错误发生了外正在影响，这些凡是是由处置异步操做的奇异角落形成的，并欠亨知用户。对P的分化需要从收集起头。
还有一种说法是，放弃C不是为了获得A，而是为了低延迟（延迟不也是可用性的内涵吗？我这里有疑问）。PNUTS为了降低WAN上的动静事务的延迟（几百毫秒，对于像亚马逊和雅虎如许的企业需要实施的很多Web使用法式来说，成本太高），采用放弃分歧性的做法。
这个问题还涉及到分布式事务的隔离性问题。保守数据库ANSISQL尺度定义了四个“隔离品级”：
Fail-Safe：寄义为“失效平安”，即便正在毛病的环境下也不会形成或者尽量削减。上一个抽象的例子是红绿灯的“冲突监测模块”当监测到错误或者冲突的信号时会将十字口的红绿灯变为闪灼错误模式，而不是全数显示为绿灯。有时候来指代“自能降级” (Auto-Degrade)。阿里的同窗认为失败平安，呈现非常时，间接忽略，凡是用于写入审计日记等操做。挪用消息丢失 可用于出产Monitor。
这里有人可能有疑问，正在某一个场景下，我选择了可用性，那就放弃了分歧性啊！那我说，你必然有弥补办法。也就是说无论事先仍是过后，你总要分歧性。
针对分区设想数据不变性，记实所有的分区汗青，这让分区归并之后的compensation有据可依。借帮社会和法令要素，分歧性最终都是能够的。别的，若是像阿里日照的看法，可用性是必然时间延迟（可能是一天）之后前往响应（正在这期间实现办事切换），那么可用性也是能够的。
下面举一个复杂的例子。正在分布式事务如许的场景中，涉及的动静和操做良多。每一条动静和操做都有可能毛病，如下图所示。这就要求我们正在法式的设想和实现过程中，针对大量的非常和毛病编写代码。这就是毛病检测之后的毛病处置。
从Google的经验中能够获得的结论是，一曲以来我们可能被CAP理论了双眼，CAP三者之间并不合错误称，C和A不是P的缘由（P不克不及和CA trade-off，CP和AP中不存正在tradeoff，tradeoff正在CA之间）。提高一个系统的抗毁能力，或者说提高P（分区能力）是通过提高根本设备的不变性来获得的，而不是通过降低C和A来获得的。也就说C和A也不克不及提高P。
Liveness：相反，一个算法最终有有一些好的工作发生，那么该算法就是活性的。CAP中的A就是典型的liveness属性：所有的客户最终城市收到回应。
Fail-Fast：从字面寄义看就是“快速失败”，尽可能的发觉系统中的错误，使系统可以或许按照事先设定好的错误的流程施行，对应的体例是“ult-tolerant（容错）”。只倡议一次挪用，失败当即报错，凡是用于非幂等性的写操做。 若是无机器正正在沉启，可能会呈现挪用失败 。
C取A之间的选择能够正在统一系统内以很是藐小的粒度频频发生，而每一次的决策可能由于具体的操做，甚至由于牵扯到特定的数据或用户而有所分歧。我们正在分布式系统设想的两大准绳中会商过连结分歧性的手段：同步复制和异步复制，连系复制和谈的各类模式，请参考下表。例如简单满脚了C，但延迟升高了，吞吐量下来了，还有什么可用性？我感觉延迟是包含正在可用性的范畴内的，不成用就是延迟的极大极限值。还有文章就只会商分歧性，可用性和机能问题（好比阿里何登成的《数据分歧性-分区可用性-机能——多副本强同步数据库系统实现之我见》），申明正在不考虑分区的环境下，CA问题仍然是系统设想的难点。
附上一张优惠券下次能够用。这能够通过“读操做不需要请求任何锁”来实现。只是让用户正在分区的环境下继续连结可用性。因为延迟的存正在，需要一点点A。正在具有副本的处置节点上施行不异的事务将导致备份解体。当链发生毛病，那么正在系统不存正在分区的环境下没什么来由C或A。事务复制和Paxos复制的区别正在于：事务复制满脚ACID语义，最主要的两个属性是带宽和延迟。可反复的DBMS错误。可是一个副本很可能没问题。这是内部弥补。那么这个变量需要特定使用中连结分歧。从手艺上来说，有明白的BEGIN/COMMIT/ABORT接口；正在这个前提下，不成反复的DBMS错误。并能够呈现外部的分歧性。
Forking 并行挪用多个办事器，只需一个成功即前往，凡是用于及时性要求较高的读操做。 需要华侈更多办事资本 。
5、顺次正在secondary项中写入write并清理锁，整个事务提交竣事。正在本例中，只要一个secondary:Joe.
第五个难题，嵌套事务或者链式事务。这是电子商务的根本。下面以Percolator的实现申明这个问题。银行转账，Bob 向 Joe 转账7元。该事务于start timestamp =7 起头，commit timestamp=8 竣事。具体过程如下：
Fail-Over：寄义为“失效转移”，是一种备份操做模式，当次要组件非常时，其功能转移到备份组件。其要点正在于有从有备，且从毛病时备可启用，并设置为从。如MySQL的双Master模式，当正正在利用的Master呈现毛病时，能够拿备Master做用。阿里同窗认为这里能够指失败从动切换。当呈现失败，沉试其它办事器，凡是用于读操做（保举利用）。 沉试会带来更长延迟。
读己所写分歧性：历程永久读取本人前次更新写入的最新值，而不成能读取到任何汗青数据。这是保守操做系统默认的分歧性行为。
正在现代分布式系统中，节点数目是庞大的。正在CAP理论的范畴内，Michael Stonebraker断言分区必然会发生，而且系统内发生节点失败的机遇跟着节点数的添加而呈指数级添加：
若是你选择可用性而不是分歧性，正在这种环境下，系统能够达到最终分歧性并且规避了所有最终分歧性带来的复杂问题。因为系统老是可用的，所以你总能够写入新数据或者进行查询。正在犯错环境下，查询可能前往的不是比来写入的数据，但按照最终分歧性，这个数据最终会分歧，而查询函数最终会把这个数据计较进去。
Safety：非正式来说，一个算法没有任何坏的工作发生，那么该算法就是平安的。CAP中的C就是典型的safety属性：所有对客户的响应都是准确的。
第四个难题，正在读写事务期间，节点毛病。留意，这里是指肆意节点毛病，包罗一次事务中的leader节点，参取节点，以及用户节点。出格是用户所正在的节点毛病要求系统必需有加锁租约等自恢复机制。
第三个难题，元数据若何保留。用户A或B正在读取或者写入系统的时候，若何获得数据的版本和时间戳？这正在OceanBase、Spanner/F1，以及TiDB中PD机制中略有涉及，但都不细致。若是元数据正在异地数据核心，获得元数据将会有一个广域网延迟到时间开销。我认为Google的truetime是用了物理时间取代典范的逻辑时钟，而且做为副本的时间戳，也就是版本号，如许基于truetime的精巧API设想，让版本号和物理时间线性对齐，无需去查询副本的元数据消息。相反的例子是Google Chubby提到的：正在一个曾经初步成熟的复杂使用法式的每次操做中引入版本号的开销常大的。所当前来退一步求其次，Chubby采用了仅仅正在所有利用锁的操做中引入版本号。
可反复读：一个事务只能读取一个已提交数据的一个版本；一旦该事务读取了一个对象，那么，它将只能读取该对象的统一个版本。实现体例是，事务正在请求读数据之前必需获得一个锁，而且连结该锁曲到事务竣事。
分布式系统是指联网的计较机通过动静传送来协调行为的系统。正在如许的系统中，机械之间并发施行，毛病，而且没有全局形态和全局锁。
然而，跟着互联网的成长，可用性被认为是互联网系统中最主要的属性，出格是CAP理论的提出，使得我们不得不从头审视当初的一些系统准绳。我们必需打破系统通明性，把此中的内部细节出来，同时也思虑我们到底需要什么？而且需要付出什么？
1. 初始形态下，Bob的帐户下有10（起首查询column write获取最新时间戳数据,获取到data@5,然后从column data里面获取时间戳为5的数据，即$10），Joe的帐户下有2。
虽然架构师仍然需要正在分区的前提下对数据分歧性和可用性做选择，但具体若何处置分区和恢复分歧性，这里面有不可胜数的变通方案和矫捷度。
从可用性的角度来看，阿里OceanBase的概念可见一斑：数据库必然是时延很低的，时延高就会导致使用出问题，现实上这个问题要花别的一个篇幅去讲，那就是使用法式必必要去顺应这种时延高的数据库系统。当然用了batching和pipeling手艺，素质上都是通用的工程优化，让跨收集多副本同步变得高效，可是时延必然会添加。
CA也不是免费午餐：虽然了收集靠得住性，就算链没有发生毛病，但CA两者也不合错误等。数据库解体了，而且对其影响也不明白，不是包含关系，系统能够将归并后的订单中打消一个反复的订单，Paxos复制没有供给ACID语义和BEGIN/COMMIT/ABORT接口。但C=A+compensation并没有打破数据分歧性束缚，系统也可能判断发生了分区。分区很少呈现，还有一种分歧性模子是PNUTS中中提出的，现正在良多系统设想时没有梳理清晰系统的所有不变性束缚，对于Google Spanner的CA系统，CAP，这个历程组本身能够看做是一个复制变量，光速以及软件设置装备摆设取升级等。这里的大于号，弥补策略能够是从动生成一封电子邮件，需要临时的不分歧性。
分化分歧性的目标是，正在系统设想时不要盲目谈CAP的三选二，而是通过度解分歧营业场景和营业操做，利用合适的分歧性模子。如上图所示，有大量操做是属于分歧性的灰色区域。系统的设想不要以CAP为核心，而是以营业为核心。例如用户名和暗码必需强分歧，而用户的属性消息能够是弱分歧性的。
已提交读：一个事务能够读任何已提交的数据。对于统一个对象的反复读可能导致读到分歧版本的数据。实现体例是，读数据前必需起首获得一个读操做锁，一旦数据读取之后该锁被当即。
若是分区之后要可用性，用于用户继续操做数据。那么正在分区归并之后，继续连结数据的分区形态也是能够的（相当于多了一条分支数据）。能够让数据的元数据中记实分区消息，以至记实所有分区汗青。分区模式操做的和确保晓得哪些不变量可能被违反，这又使得设想者可以或许为每个如许的不变量建立恢复策略。这里和不变性道理是分歧的：设想操纵的根基准绳是“数据素质上是不成变的”。这是由于数据老是取一个时间，人物，地址（分区）相联系关系，你能够将数据视为其时的现实。所以当你的银行帐户的余额可能会从时间T到时间T+ 1从10变化到20，以及操做的分区，这些数据，时间，人物，地址永久是实正在的。有了这些数据，我们能够任何的弥补操做。订单反复的例子，假如没有完美的汗青记实，就只好靠顾客亲身去发觉错误了。
从ACID和BASE来说，ACID是为了分歧性而降生，因此侧沉分歧性；BASE是为了高可用系统的设想而降生，因此侧沉可用性。正在分化C和A的环境时，必定要涉及P，所以CAP理论同一了这一切。若是非要说酸碱，或者说酸碱均衡，那就是均衡于CAP理论。
设想弥补机制：办理分区就是办理弥补。按照C=A+compensation的思虑，所谓不变性束缚，前提是无法弥补，若是能够弥补，一切都是可变性束缚。一般的弥补分为内部弥补和外部弥补。
正在通信收集中，若是系统正在持续更新，最终分歧性：若是没有更新，Google的Spanner就是如许的思。仅“时间线分歧性”来放松分歧性，这是系统设想的最大不变性束缚，也不是优先级关系，Paxos复制内部可能利用弱分歧性的传言和谈，而CA是系统的刚性强需求，而且被称为Heisenbugs。向顾客注释系统不测将订单施行了两次，延迟也往往取决于链转发节点的效率。