asp.net做网站有何意义,贵阳网站建设q479185700棒,企业网站找谁做好,网站建设售后服务承诺一、强一致性 一致性大家庭中#xff0c;虽然细分种类很多#xff0c;但是实际上只有两大类#xff0c;其中之一就是强一致性#xff0c;其具体包含了严格一致性(也叫原子一致性或者线性一致性)和顺序一致性。 严格(原子/线性)一致性
严格一致性代表着#xff0c;当数据更…一、强一致性 一致性大家庭中虽然细分种类很多但是实际上只有两大类其中之一就是强一致性其具体包含了严格一致性(也叫原子一致性或者线性一致性)和顺序一致性。 严格(原子/线性)一致性
严格一致性代表着当数据更新后所有Client的读写都是在数据更新的基础上。如下图所示我们假设每份数据有三个副本分别落到三个节点上。当Client1尝试将X的值置为1时严格一致性要求当Client1完成更新操作以后所有Client都要在最新值的基础上进行读写这里的Client10读取到的值是x1在同一时刻Client100的更新操作也是在x1的基础上进行x1操作在下一个时刻Client1000读到的任意一个副本X的值都会是2。 此时你会发现一切似乎都是很完美的。但是仔细想想严格一致性的背后有什么潜台词呢
1数据同步复制
严格一致性代表着所有数据在写入操作的时候是同步复制的即写多副本都成功才算写入成功HDFS是不是就是最好的例子。并且具有原子性对于写入操作来说结果要么写成功要么写失败不存在中间状态。这也是为什么称为原子一致性的原因。
2严格一致性不考虑客户端
在网上有很多人在解释一致性时尝试从客户端和服务端分别解析但是在上一篇我们分析CAP的时候也有提到不要带Client玩那么究竟谁对谁错呢
这里我们再来看下在考虑分布式系统的一致性时我们更关注什么是多个Client发送读写请求到达后端的时间和先后顺序嘛不我们真正关注的是每个请求对应服务端完成时间点的先后顺序。还是参考上面的例子Client1000读取到x2这个结果实际上是以Client100这个写操作完成为基础的如果Client100写操作一直不完成那么强一致性要求Client1000读取到的X是1而不是2。因此我们更需要关注的是完成操作的具体时间点而不是操作发起的时间点对于一致性来说考虑Client的意义就不大了。当然在同一时刻多个Client操作的幂等性还是一定要保证的。
换个角度Client才是一致性需求的甲方不是嘛。而分布式系统端作为乙方只能满足甲方需求或者拒绝甲方需求而不是要求甲方作出任何改变
3) 基于严格的全局时钟
上面我们提到操作行为完成时间点的顺序是十分重要的。再仔细看一下上面举例的内容相信你会发现一切的行为都在时间这个维度上行为顺序是Client1更新x1 - Client10读取x1/Client100在x1的基础上更新x1 - Client1000读取x2。所以每个操作都是在前一个操作完成的基础上进行的在分布式服务中需要有一个基准时间来衡量每个操作行为的顺序。此时你会问了机器上不是都有NTP做时间校准嘛现在的问题就是无法保证每一台机器的时间都是绝对相同的。
举个例子数据D2所在的节点相比D1节点时间提前了几秒当Client1的更新请求完成后(用时500ms)Client10的请求开始执行并完成如果将机器时间作为基准就会发现Client10的读取操作竟然在Client1的更新操作之前这显然是违背强一致性的。
我们一般我们会如何保证全局时钟这里简单聊聊三种种常见解法。 混合逻辑时钟 Hybrid Logic Clock
在混合逻辑时钟中同时比较了节点本地的物理时间、逻辑时间和其他节点发送消息中的物理时间。kudu和Cockroachdb也都是使用的这个方法HLC虽然加上了物理时间但是仍然强依赖于机器的NTP并不是严格意义上精确的时钟在HLC中需要为时钟定义一个边界比如kudu中定义了maximum check error(最大时钟错误)如果本地NTP没启动kudu在启动的时候就直接失败了如果误差超过了maximum check error依旧会报错这也就意味着当超过HLC所设定的偏差边界HLC就不能正常工作了。
在看HLC的实现逻辑时发现步骤比较多逻辑时间存在的意义就是在时间比对时当作中间值或者备份值。这里由于不是本篇重点不再赘述了感兴趣的小伙伴可以看下论文https://cse.buffalo.edu/tech-reports/2014-04.pdf。 True Time
上一篇文章中也有讲到谷歌依赖强大的基建实力降低了网络分区发生的概率而面全局时钟问题Google的Spanner采用的是GPS Atomic Clock(原子时钟的含义可以百度一下)这种纯硬件方式来对集群的机器进行校时其精度在ms级别这里我们用ε来表示时间精度的误差时间的精度误差的范围也就是[t-ε,tε]这个范围之间。此时回到上面的操作中按照此种方式Client10的机器时间相比Client1的机器时间最多提前或者滞后2个ε的时间因此Spanner引入了commit wait time这个方案说白了就是操作执行完成后多等一会等过了这个精度误差的范围自然就全局有序了Google将精度误差控制在几ms级别当然对于Spanner这种全球性、跨地域的分布式系统来说多等个几ms问题也不大。
但很遗憾Google的这套硬件解决方案并没有开源出来适用性有限我们就望梅止渴吧。 授时中心 TimeStamp Oracle
在生活中也有”授时中心“的存在貌似在陕西具体位置可以查查他的作用是什么呢为中国各种基建、系统提供了一个准确的时间避免误差。个人YY万一打起仗总不能因为其他国家干扰了基准时间咱们所有基建就瘫痪吧因此授时中心的意义巨大。
在分布式服务中实际上也有类似的方案。这里以Tidb举例Tidb为了校准时间就是采用了TSO这个方案对于Tidb来说所有行为事件统一由PD节点分配时间虽然这种方案会产生非常高频的互相调用但是按照Tidb官方介绍在同IDC网络环境下网络传输开销非常低只有0.xms。当然如果面对跨IDC的网络就可以尝试将PD节点和Tidb节点混部(Tikv依然需要独立部署为的是存储计算分离)。这就不需要走网络的开销了当然如果是Client端跨IDC的话还是没有太好的方法。 顺序一致性
上面我们说到了严格一致性(线性/原子)想做到全局时钟下的全局绝对有序是有难度的HLC实现比较复杂谷歌的原子钟GPS又没有开源出来TSO又增加了系统的复杂度。想实现全局时钟好难
这里我们是否可以退一步舍弃“时间”这个有序的计数器尝试构造一个更好维护的计数器不保证全局行为绝对有序只保证分布式服务全局相对有序
如下图所示D1先后更新了x1x2D3先后更新了a1a2。当Client读取到D2节点时按照顺序一致性要求所有节点的操作相对顺序都是相同的一定是x1在x2之前a1在a2之前下图举例的是顺序一致性的其中一种情况。 1逻辑时钟 Logic Clock
逻辑时钟Logic Clock这个名字你陌生的话或许他的另一个名字Lamport Timestamp会让你浮想连连如果你还是没啥印象的话那么Paxos你是否知道呢如果做大数据的你不知道paxos那你需要好好补习下基础了。Lamport Timestamp和Paxos的作者实际就是同一个人——LamportPaxos在分布式系统一致性算法中是教义般的存在由此可见逻辑时钟Logic Clock也不会差到哪里。 如上图所示在Logic Clock算法中每台机器内部都会记录一个时间戳以A、B举例 其初始值是0。每当机器A、B执行了一个事件那么他们各自的时间戳就会1,当A向B发起通信的时候A会附带自己的时间戳比如message,timestamp这时B会比较消息中的时间戳和本地时间戳选取最大值max(local timestamp,message timestamp)更改本地的时间戳。通过这种方式构建了一个新的计数器实现了全局相对的顺序性即本地timestamp 1 远端选择max timestamp即使各个节点时间不同但是操作执行是有序的但是问题也很明显就是新的计数器无法和实际时间做匹配。
2ZooKeeper是怎样的一致性
这里我们暂时不谈共识算法Paxos(请持续关注后续文章)。我们直接来说说ZooKeeper的一致性网上很多资料都说zk是最终一致性很抱歉zk是强一致性的并且是强一致性中的顺序一致性。为什么不说zk是最终一致性的原因呢
1 就好比你考试考了99分你非得说考了60分。这不止代表着分数最终一致性拉低zk的档次直接从强力档拉到了弱鸡档。
2 此外你参考本篇中最开头的图来看zk是CP系统。从CAP反向来推导如果zk是最终一致性那么意味着是AP系统但是zk在选举的时候实际上是不可用的也就是A达不到此时就发生矛盾了。
ZooKeeper中的Zxid实际上就是逻辑时钟Logic Clock中自造的计数器可以发现以Zxid为基准可以做到所有节点识别到的操作顺序都是相同的。就像上面说的Zxid是是无法跟实际时间相对应的。网上很多资料说ZooKeeper的写入是线性一致性对此我是不认同的涉及到的两段式提交(后面的文章会讲到)不带回滚却会主动同步某种意义上讲是线性的但是当commmit阶段时发生了网络分区了这时数据就不会同步到异常节点上如果此时再有一个Client访问到这个节点此时读到的就是旧数据了。其写失败意味着所有节点都写失败而写成功却意味着不一定所有节点都写成功。因此个人认为只能算顺序一致性而不能算线性一致性。
3举个栗子
如果对顺序一致性还没有什么概念那么你可以理解为分布式系统就是微信朋友圈当我我发了一个朋友圈之后周杰伦看到我的朋友圈后开始评论紧接着王力宏又评论了。顺序一致性代表着当我们共同的朋友林俊杰看朋友圈时一定是先看到周杰伦的评论再看到王力宏的评论当朋友吴亦凡看到时可能只能看到周杰伦的但是王力宏的评论也许会迟到但永远不会缺席。并且永远不会存在王力宏的评论在前而周杰伦的评论在后的情况。 三、弱一致性
一致性家族中的另一大类就是弱一致性了相比强一致性弱一致性在保证可用性的基础上允许出现数据不一致的情况。 为什么一致性会分强弱
按照上一篇CAP的理论CAP中的一致性。而在实际需求中会发现越来越多的分布式系统都更看重可用性A而不是一致性C。高可用性要求我们的系统面对Client的读写请求在规定时间内必须返回结果并且不会报错。
面对不同场景各类AP系统也只能在弱一致性方面下大功夫。也因此出现了非常多的弱一致性模型下面我们就逐个来分析下。 最终一致性
上一篇我们在BASE中所提到的就是最终一致性其并不保证在任意时刻、任意节点上的同一份数据都是完全一致的但是随着时间的迁移不同节点上的同一份数据总是在向一致的方向变化。其中数据不一致的时间段称为非一致性窗口。简单说就是数据写入的一段时间后各节点的数据最终会达到一致状态。如下图所示。 因果一致性 因果一致性强调了数据之间的因果关系初始状态X的值为1当D1将X的更新为2后这时D1会和D2节点进行通信将D1,D2,X,2这条消息传递给D2后续D2节点所有的读写都是在新值基础上进行的。此时D3节点还是会在非一致窗口内读到X的旧值1。因此D1更新数据并通信D2为因D2接受通信修改本地状态为果此为因果一致性。 “读你所写”一致性
什么是读你所写一致性呢顾名思义读到你所写的数据,在因果一致性中定义的是集群节点间更新通知的机制而对于“读你所写”一致性来说也是沿用这个思路不过这里通信的是本节点影响的也是本机后续的的所有读写请求因此读你所写一致性其实是因果一致性的特殊场景由于原理相似下面直接放图。 会话一致性
会话一致性以会话为基础通常应用于类数据库系统的场景。每一个会话相当于一个独立的访问链接在这个会话中可以执行很多具体的读写操作且会话之间是相对独立的。
如下图所示会话一致性要求只要会话1还存在会话内就保证“读你所写”一致性。如果D1的会话1终止那么当重新建立会话2时在不一致窗口内即使是同一个节点的会话也不保证数据一致。因此会话一致性又是读你所写一致性的特例(是不是感觉有点乱一个特例又一个特例的没关系最后的时候我们聊下各种一致性的关系加油 单调一致性 单调一致性分为读、写两个层面即单调读一致性和单调写一致性。实际上很好理解单调读保证了整个系统读必须有序的假设X的值递增读X2一定是在读X1之后。而单调写保证了写必须有序的对于整个系统来说写X2一定是在写X1之后。这里比较好理解我就不正图了(画图画吐了)。个人认为单调写一致性应该是大部分分布式服务的基础。否则如果你写入顺序无法保证你想想都会感到痛苦。
三、各种一致性的关系和常见误区 各种一致性的关系
如下图所示一图厘清一致性之间的关系如果此时相关概念有忘记可以再重新看下上面的解析 误区一强一致性线性一致性
网上非常多的资料动不动就强一致性就是线性一致性或者把顺序一致性放到和强一致性相同的级别来比对这些其实都是错误的正如我们上面看到的强一致性包含线性一致性和顺序一致性。也因此强一致性不一定是线性一致性但线性一致性一定是强一致性。 误区二一致性并不是非黑即白的
强弱一致性之间并不是泾渭分明的一个分布式系统可能同时满足其中的一种或者多种。咱们还是回到ZooKeeper上其同时符合顺序一致性最终一致性。一致性种类满足的越多符合的场景也就越多当然其复杂度也就越高。从这一点我们就可以看出没有一个能满足所有场景的分布式系统如果真的有那么他的数据一致性逻辑必然十分复杂。
