网站关键词怎么优化到首页,谷歌搜索优化,培训机构退费法律规定,用wordpress做视频在分布式领域里#xff0c;一致性成为了炙手可热的名词#xff0c;缓存、数据库、消息中间件、文件系统、业务系统……#xff0c;各类分布式场景中都有它的身影#xff0c;因此#xff0c;想要更好的理解分布式系统#xff0c;必须要理解“一致性”这个概念。
其实关于…在分布式领域里一致性成为了炙手可热的名词缓存、数据库、消息中间件、文件系统、业务系统……各类分布式场景中都有它的身影因此想要更好的理解分布式系统必须要理解“一致性”这个概念。
其实关于一致性的讲述之前聊《深入浅出 -- 系统架构之分布式CAP理论和BASE理论》这两个分布式理论时也曾提及过讲到CAP一致性是数据一致性BASE一致性则是指状态一致性不过当时讲的不够具体、不够体系化更多是围绕着两个分布式理论在阐述而本文就展开聊聊 分布式系统里的一致性模型。 一、重要的一致性模型
回想《深入浅出 -- 系统架构之分布式CAP理论和BASE理论》聊到的一致性
CAP一致性任何时间点在任意节点上看到的数据完全一致BASE一致性数据只能从一个一致状态变化到另一个一致状态。
CAP理论针对的是数据一致性主要关注怎样维持多副本的一致性视图即如何使多个节点上的数据对外表现的和一份数据一样。BASE理论关注状态一致性主要在于根据业务需求操作不同节点的数据时最终实际执行结果和我们的观念一致即分布式系统中的业务操作执行完成后结果都在预期之内而不是部分成功、部分失败这种预期之外的结果。
这两个一致性的定义涵盖了分布式系统中的所有场景建立在这两个定义的基础上又存在三种较为重要的一致性模型即强一致性、弱一致性、最终一致性这三个一致性模型作用在数据一致性、状态一致性上的含义并不相同为了更好的说明不同的一致性模型我们先针对数据一致性、状态一致性分别给出个例子后续分析会建立在这两个案例的基础上进行展开探讨~ 实际一致性模型只有强一致性、弱一致性两大类之分所有不满足强一致性要求的都能被称之为弱一致性因此最终一致性是一种另类的弱一致性体现而弱一致性还有很多其他的细分如顺序一致性、因果一致性、会话一致性、客户端一致性、单调读一致性、单调写一致性等多种这里暂时不做展开后续会简单提及。 数据一致性案例互联网大流量的背景下为了保证服务可用性通常会采用集群化模式部署以此实现任意节点故障都不会影响系统正常的对外服务能力 如上图所示这是一个十分典型的高可用场景采用集群式部署当外部向系统写入一个值X后该值会被同步给集群内剩余两个节点从而保保证所有节点的数据一致性流量切至任意节点都能确保看到的数据相同。
状态一致性案例为了尽可能提升系统吞吐量也会将原本单个庞大的系统拆分成多个子系统/微服务运行一个业务需求由多个服务一起满足多个服务之间通过远程调用来进行交互与通信如下 这是一个简化到极致的下单场景只由创建订单、扣减库存两个动作组成在分布式系统中每一个下单请求都会执行这两步操作。按照我们的观念创建一笔订单后相应的库存都会进行扣减这样的结果才符合设想的预期而这种符合我们预期的结果则满足状态一致性的要求毕竟整体数据的变化是一致的具体可参考《状态一致性》。
好了有了上述两个案例作为分析的基础下面来对常见的三个一致性模型进行展开。 1.1、强一致性模型
强一致性又称原子一致性、线性一致性、严格一致性、实时一致性……它是一种苛刻的一致性要求这是实现难度最高、可用性最低、性能最差的一致性模型先来看看数据的强一致性。
1.1.1、数据强一致性
还是这幅图 当外部写入X值在A节点成功后B、C节点应该立即能看到此数据只有这样才是满足强一致性要求的。这个要求听起来没啥特别但要注意集群内各节点的数据同步工作依靠网络完成走网络需要时间成本无论如何优化A和B、C节点间都会存在短暂的不一致而这就打破了“强一致性”的要求。
那该怎么做在之前有提过如果想要保证所有节点的数据强一致那就在数据写入时下功夫即X写入A节点后并不代表X写入成功需要继续在B、C节点写入成功后才算数据写入完成这样就能保证强一致性。当然这样还不够对数据读取请求也得进行控制如下 当数据在A、B节点写入完成、C节点正在写入中此时去C读取数据会怎么样答案是看到X1这个旧值当请求去A读值为了保证看到的数据相同这时A就不能返回X2这个新值而是同样返回1需设计类似于MVCC这种多版本并发机制这样才能保证所有节点的强一致性。
1.1.2、状态强一致性
前面说清楚了数据的强一致接着来聊聊状态的强一致性回到最开始给出的下单场景 想要保证这个场景中的状态强一致意味着需要保证创建订单、扣减库存操作一起完成即订单服务创建订单后不能立马将订单数据提交必须等扣减库存成功才行。如果扣减库存未完成前面的订单数据就需要一直阻塞等待也就是典型的XA事务模式在分布式场景中咋实现
首先要引入独立的事务管理者分布式事务对应的多个操作会被视为一个“事务组” 上述下单场景中两个动作分别对应着两个子事务在创建订单后首先订单服务会向事务管理者中注册一个事务组而后把创建订单的执行结果成功或失败提交给管理者接着商品服务开始执行执行完成后也会将结果加入到前面创建的事务组中。
两个子事务均已抵达事务管理者后事务管理者会做统一的决断当事务组所有子事务都执行成功后才会真正向该组事务的参与者下发“提交事务”的信号此时整组事务才会真正被提交。同理只要一个子事务失败整组事务都需要被回滚具体原理可参考《手写分布式事务框架篇》。
上述方案中在事务管理者没有下发最终处理结果之前所有子事务都需要阻塞等待从而保证状态的强一致性整体数据一起从一个状态转变为另一个状态。尽管这种方式能实现接近于ACID原则的强一致性效果可对应的代价是牺牲掉一定的可用性一方面阻塞的事务会长时间占用着数据库连接不释放另一方面则会延长接口响应时间影响整体的性能。
1.2、弱一致性模型
聊完了强一致模型接着来看看弱一致性模型它与强一致截然相反即虽然我提供了一致性的支持但系统可能会出现不一致的现象对这种不一致的情况我也不保证它最终会变成一致的结果。这有点类似于Redis提供的“弱事务机制”Redis虽然提供了事务相关的命令支持但它并不保证事务一定生效并且对于失效的现象不会有任何补救措施下面套进案例中讲述。
1.2.1、数据弱一致性 依旧看到这幅图当外部写入X1的数据到A节点后立马会向客户端返回写入成功而数据如何交给B、C节点呢通过异步的方式完成。如果异步复制时出错好比B节点在同步时宕机就算恢复后也不会管X这个值毕竟“我”是弱一致性呀如果你运气好写进来的值在所有节点里最后肯定会一致如若运气不好丢了就丢了跟我没关系~
综上数据弱一致性模型在写入成功后即不保证相同时刻所有节点读到的值相同也不保证故障节点恢复后会和其他保持相同的最新数据。
1.2.2、状态弱一致性
相信经过前面的案例大家也能猜出来弱一致模型作用在“状态”上的效果即正常情况下创建订单和扣减库存都会正常提交此时整体数据的变化是一致的订单数据、库存数据都从“初始态”变成了“结果态”。可是在不正常的情况下有可能碰到“订单有了、库存没扣”这种状态不一致的变化就这种情况来说弱一致模型不会做任何处理。
大家能很明显的感受出弱一致模型其实很不靠谱它不承诺会数据/状态会立马一致也不承诺多久后能达到一致只尽可能保证正常情况下的一致性但凡出现特殊情况就会造成不一致的场景出现。
1.3、最终一致性模型
一开始提到过最终一致性是弱一致性的另类表现也是最重要的弱一致性模型也是各种分布式系统中最推崇的一致性模型即不保证数据/状态立马一致但保证经过一定时间后最终肯定能收敛到一致状态。
1.3.1、数据最终一致性 此时外部请求将X值从1更新成2在A节点更新成功后立马返回X2这个值通过异步方式同步给B、C节点。而在“A节点写入成功、B、C节点同步完成前”这段时间内属于“不一致窗口”如下 如上图所示在不一致窗口内在不同节点有几率看到不一样的值但这种不一致的现象很短暂随着不一致窗口结束集群内所有节点依然会保持数据的一致性。同时对于B节点同步时发生故障这种现象在B节点恢复后会用自身数据和集群其他节点比对如比对POS点如果发现其他节点的数据更新则自动从最新的节点上拉取数据以此实现最终一致性模型。 大多数存储型组件实现的主从集群其支持的异步复制、半同步复制模式就是最终一致性模型的落地。 状态的最终一致性在分布式理论篇的《重新理解BASE理论》阶段有结合案例讲解 因为之前写过这块所以不再重复赘述下面总结一下常见的三种一致性模型。
1.3.2、常见的一致性模型小结 前面简单讲述了三种常规的一致性模型强一致性最理想但性能方面不可直视弱一致性性能很棒可是太不靠谱而最终一致性则是弱一致性的特例在弱一致性模型中在保证性能的同时也尽力保证了一致性最多只会出现一定时间的“不一致窗口”换到生活中三种一致性模型的释义如下
强一致性我们在一起吧现在就去民政局领证弱一致性我们在一起吧结婚看情况咯能结就结吧结不了就算了。最终一致性我们在一起吧虽然现在不能立马领证但最后我们肯定会结婚的。
好了对这三种常见一致性模型有了认知后接着来看看弱一致模型中的其他衍生如前面提到的顺序一致性、因果一致性、会话一致性、单调读一致性、单调写一致性等等不过弱一致性模型的大家族中只有最终一致性模型较为重要剩余这些简单了解即可。
二、弱一致性大家族
上面提到了一堆“一致性模型”但其实很多模型是用在CPU多核架构上而并非是针对分布式领域提出多核架构的CPU允许多条线程并行执行而多线程执行是无序的这些模型定义了 不同线程并行执行时如何保证CPU寄存器、CPU高速缓存区、机器内存之间的数据一致性。 当然本阶段只简单探讨这些一致性模型不对各类操作系统中的具体实现进行分析如因特尔的MESI协议其他厂商的MOESI、MSI、MOSI、Synapse、Firefly、DragonProtocol等等感兴趣的小伙伴可自行去研究。 2.1、顺序一致性
顺序一致性从它的名字应该也能猜出大致含义它并不要求数据或状态要严格一致但起码要保证顺序的一致啥意思来看例子 客户端分别按序将A中X值变更成1、2、3接着按照向节点B依次同步可是在同步X2这个值时由于网络延迟问题导致比X3要晚到B节点因此B节点会按1、3、2的顺序进行同步。这时当读取请求分别去到A、B节点读X值就会不一致。
顺序一致性则是约束上面说的这种现象它并不要求A更新的值立马能够在B看到但起码要按照写入A的顺序去同步数据不管遇到何种问题一定要保证B节点上读取时和A节点相同同理换到之前分布式事务的例子中下单流程是先创建订单、再扣减库存总不能库存已经扣了却没有对应订单产生MQ的顺序消费也有这个含义在里面。
2.2、因果一致性
因果一致性并不要求完全满足顺序一致但要保证因果一致来看例子 外部按序向A写入X1、Y1、X3三次值其中X1、X3写的是同一个数据两个操作之间存在因果关系。此时就必须保证B节点上X3的同步工作要发生于X1之后如图中所示X1同步出现网络延迟导致X3先完成同步此时从B读数据就会先读到X3再读到X1这就颠倒了因果关系。当然至于不存在任何关联关系的Y1随便打乱顺序到任何时间点都行
大家观察会发现因果一致性比顺序一致性更宽松不要求全局所有顺序一致但必须存在“因果关系”的操作则要保证顺序的前后性。不过怎么判断两个操作间是否存在因果关系不同的分布式系统或许有不同的设定上面的案例属于一种数据依赖因果关系再来看个例子 小竹在平台充值9.9元巨资先走交易中心完成支付接着异步更新账户中心的余额并将“支付成功”的消息发送到MQ推送中心立马监听到支付消息于是触发推送机制从账户中心读取旧余额0.00元并向小竹推送了一条信息 “充值成功您的余额为0.00元” 这合理吗答案显而易见。在这个例子中更新账户余额、读取余额推送两者存在因果关系必须要保证更新余额先发生于推送之前否则就会出现上述问题这则是业务逻辑上的因果关系。
再来个例子比如分库分表中订单分了四个库小竹下了一笔组合单生成订单时被系统自动拆分成了三个子订单。在订单数据分片时主订单和其中两条子订单落入到第一个节点而另一条子订单落入到第三个节点后续关联查询时就无法查询出组合单的所有子单。
在订单数据分片场景中主单、子单存在因果关系必须让这种具备因果关系的订单同时落入到一个节点中这样才能保证后续查询的订单信息一致类似的场景还有很多总之存在主外关联关系的数据在进行分片存储时相同主键的数据一点要落入到相同节点。 PS其实还有很多因果一致性的场景这里不再一一例举经上面阐述相信大家能理解因果一致性模型。 2.3、会话一致性
会话一致性相信这个大家并不陌生在很早之前的开发业务系统时用户登录后的信息通常都会直接存储在服务端的Session里接着给客户端如浏览器返回一个SessionID当同一个已经登录过的客户端再次请求系统时就能直接根据SessionID拿到前面的登录信息从而避免本次请求进行重复登陆。
上述这种方案将系统集中式部署在单台机器上这是没有问题的可是换到分布式系统中如采用集群模式部署这时就会出现问题集群内每个节点都有自己的Session存储空间当客户端请求第一次去到A节点并登录成功第二次请求分发到C节点因为登录凭证存储在A上面所以C又会要求客户端重新登录。 这对客户端来说显然并不合理明明我刚刚才登陆过凭什么又叫我登录啊这就是分布式系统中的会话不一致问题。不过这类问题解决起来很容易只需要将原本保存会话信息的空间挪出来让所有节点共享即可。
好了上面是会话一致性的一种体现在分布式存储系统中会话一致性有着不同的释义。具体来说它保证在同一个有效的会话中一旦客户端更新了某个数据项的值那么在这个会话中客户端在读取这个数据项时将不会读到比这个更新值更旧的值。
大家看这个定义是不是和“事务机制”有点类似比如在MySQL中T1事务将ID1的name字段从ZhuZi更新为XiongMaoT1事务再次查询ID1的数据行时将不会读到XiongMao之前的name值。当然如果事务T2读取ID1的数据呢并不保证能读到最新的值毕竟T1可能还未提交事务。
在分布式存储系统中同理会话一致性保证客户端在进行更新操作后在同一会话中始终能读到该数据项的最新值。不过它只保证单次会话内数据的一致性而对于不同会话间的数据一致性则没有保障。 三、客户端一致性
客户端一致性针对的是分布式存储领域是站在一个客户端的角度观察系统的一致性它确保了同一客户端对相同数据访问的一致性但并不为不同客户端的并发访问提供一致性保证。再来看到这幅图 在之前聊到的最终一致性模型中一个客户端在“不一致窗口”期间内访问不同节点的同一数据时由于数据复制的延迟性可能会出现读到不同的数据。为了解决此问题业界提出了以客户端为中心的一致性模型客户端一致性涵盖了多种策略
①Writes-Follow-Reads Consistency写跟随读②Pipeline Random Access Memory管道随机访问存储③Read Replica Selection读取副本选择④Read Consistency Level读取一致级别⑤Write Commit Level写入提交级别
这些策略都是用来保证在同一个客户端的视角下相同数据的读取和写入是一致的但不同策略在数据一致性、延迟、吞吐量等方面有不同的权衡和取舍下面咱们来挨个看看。
3.1、写跟随读策略
Writes-Follow-Reads Consistency写跟随读也称为会话因果一致性session causal即会话一致性、因果一致性的“组合版”这是一种确保客户端读取和写入一致性的策略它强调在一个客户端的读写操作中写操作应该跟随之前的读操作以保证数据的读写一致性。
写跟随读策略要求当客户端读取某个数据项的值后如果它随后决定写入一个新值那么这个新值必须是在读取时看到的值的后续版本啥意思来举个例子。 假设你正在玩QQ飞车在游戏中每个玩家都有自己的赛车和位置当你开始游戏后你会从服务器那里读取当前的游戏状态比如其他玩家的位置和速度这就是一个“读操作”。 游戏中途你决定通过“氮气加速”并超过前面的玩家你按下加速按钮就相当于一个“写操作”你希望服务器更新你的赛车的速度和位置并同步给其他玩家。 套入写跟随读策略的概念在你按下加速按钮后服务器应该基于你之前读取的游戏状态来更新你的位置。也就是说你的新位置应该是基于你当时看到的其他玩家的位置和速度来计算的。 简单来说写跟随读一致性就像是你玩游戏时你的动作写操作应该基于你当前看到的游戏状态读操作来执行。比如当一个客户端第一次读取X值为1接着写入了X2那从当前客户端的角度来看X值的读取和写入操作是连贯和一致的。
3.2、管道随机访问存储策略
Pipeline Random Access Memory简称PRAM虽然我感觉翻译过来叫“管道随机访问存储”有点怪但我们不做过多纠结。PRAM也是一种保证客户端一致性的策略它要求客户端一直连接同一个节点进行读写操作从而避免了因延迟性导致的数据不一致问题还是之前这幅图 当一个客户端先在A节点将数据X更新2之后接着再去C节点读取X值因为同步存在延迟所以出现了不一致窗口导致读到X1这个值。PRAM策略的解决方案很简单既然你是在A节点写入的数据那你后续读取X值时就去到A节点读取这样就能避开不一致窗口保证数据读取的一致性。 PS如果一个新的客户端去到B、C节点读取X值时还是会看到不一致的数据毕竟PRAM只是客户端一致性策略无法为不同客户端的并发访问提供一致性保证。 当然其实PRAM可以拆解成三种一致性模型相信部分小伙伴接触过即单调读一致性、单调写一致性、读己所写一致性下面简单聊两句。
3.2.1、单调读一致性Monotonic-read Consistency
单调读一致性指的是一个客户端读到一个值后后续该客户端中任何一次读取都能看到该值或者该值之后的新值而不会读取到之前的旧值同样来看案例 上图中总共读了三次X第一次读的值为1由于中途更新过一次X因此第二、三次为2这个案例则满足单调读一致性即第二次读到了2第三次也肯定能看到2而不会看到第一次读取时的1也就是说相同客户端后续发起的读操作都能感知到先前读取到的值或者更新的版本值而不会读到比上一次读取更旧的版本值。
3.2.2、单调写一致性Monotonic-write Consistency
单调写和单调读类似只不过说的是写操作即客户端后续发起的写操作都能感知到先前写入的值或者更新的写入版本。这和顺序一致性有点类似客户端按序写入X1、2、3那么写入2的动作肯定发生于1之后写入3同理。
当然单调写一致性针对的是多主类型的场景如下 这里A、B都为主节点具备处理客户端写入动作的能力如果客户端按序写入X1、2、3的动作其中X1、3落入AX2落入B节点那么A在执行X3时必须感知到X2否则就有可能出现X2在X3之后执行最终相互同步数据时X2因为是最后执行所以X的最终值变成错误的2而不是预期的3。
3.2.3、读己所写一致性Read-your-writes Consistency
读己所写有的地方也叫读你所写一致性即客户端后续发起的写操作能感知到自己先前写入过的值 还是这个熟悉的图这里在第一次读取、第二次读取之间写入过一次X2因此在第二次读取X值时就能正确读取到自己写入的X2。
综上其实大家会发现PRAM策略因为要求客户端一直连接着同一个节点执行读写操作所以对相同的客户端来说它的读写操作必然满足单调读、单调写、读己所写这三个一致性模型。
3.3、读副本选择策略
Read Replica Selection读副本选择策略在分布式系统中由于数据被复制存储在多个副本上客户端在读取数据时可以选择从哪个副本读取。读副本选择策略可以基于多种因素如副本的地理位置、网络延迟、负载情况、数据新鲜度等选择一个最合适的副本读取可以提高读取性能、减少网络延迟并确保读取到的是最新的数据。
一种常见的策略是选择离客户端最近的副本进行读取以减少网络传输延迟例如CDN内容分发技术为了提升客户端访问静态资源时的速度通常大型C端系统都会采用CDN来缓存静态资源客户端在请求静态资源会自动根据客户端的IP地址通过智能DNS解析技术选择距离客户端物理距离最近的CDN站点获取数据并返回具体可参考《CDN内容分发》。
另一种策略是根据副本的负载情况来选择即负载均衡算法里的最小连接数算法根据集群各节点的实际负载情况将请求智能化分发到负荷最低的节点避免负荷过载的节点被频繁访问造成响应缓慢、节点故障等现象。 PS也可以根据数据新鲜度则POS点来分发读取请求路由节点只需要记录集群内每个节点同步数据的POS点即可读取请求优先分发到POS值更大的节点处理毕竟POS越大代表同步的数据越多意味着数据会越“新鲜”。 3.4、读一致性级别策略
Read Consistency Level读一致性级别策略关注的是客户端在读取数据时对于数据一致性的期望和要求。不同的应用场景对读一致性有不同的要求它可以根据业务需求来切换读取的节点。
比如在MySQL主从架构中某些业务要求强一致性要看到最新的数据这时可以将请求路由到主节点处理而部分业务可以接受稍微陈旧的数据则可以分发到从节点处理。又或者在MongoDB集群模式下读取数据可以设置readConcern参数实现读取时选择不同的客户端一致性保障具体可参考之前《MongoDB保姆级指南》或《MongoDB官网-可调一致性》。
总之在分布式存储系统中强一致性读通常需要更多的同步和协调机制可能会增加延迟或成本而弱一致性读则可以提供更高的性能和可用性。因此在选择读一致性级别策略时需要根据业务的需求进行权衡。
3.5、写提交级别策略
Write Commit Level写提交级别策略主要涉及的是写操作的提交方式写提交级别决定了写操作在分布式系统中的提交方式和时机。与读一致性级别策略类似写提交水平也有多种选择如下
同步提交要求系统内所有节点都写入数据成功后才认定为写操作成功异步提交只要求客户端连接的节点写入数据成功后就认定为写操作成功多数提交要求系统内部分节点通常是节点数的一半以上写入成功后就认为写操作成功。
上述三种提交级别正好对应着大多数技术栈中同步复制、异步复制、半同步复制这三种主从数据同步模式同步提交能保证数据的强一致性但可能会增加延迟和降低性能。异步提交可以提高性能但可能会牺牲一定的一致性。多数提交是前两者的妥协性能、一致性之间做到了平衡属于中庸方案。当然在在实际项目中究竟选哪种模式需要根据业务数据的重要性和应用的性能要求综合选择不同的写提交级别。
MongoDB在写入数据时也支持通过writeConcern参数来指定写提交级别如下 四、一致性模型篇总结
任何一个分布式系统底层都离不开一致性模型的支持我们通篇读下来会发现各种各样的一致性模型实际都是在描述了客户端和系统交互的一系列规则。其中强一致性是对客户端最友好的模型它不要求客户端留意任何规则允许客户端在任何时刻发起任意请求系统都能返回一致的结果可这种方式对系统本身来说额外影响性能、吞吐、可用性。
根据CAP定律一致性、可用性两者之间存在本质矛盾。在实际的分布式领域里并不是所有系统都看重实时一致性有时候某些系统反而更加追求性能、吞吐、可用性。正因如此根据不同的使用场景诞生出了不同的一致性模型有些模型种放松了对外的一致性保证由客户端来容忍特定的不一致行为进而换取更好的性能。
就目前为止本文汇总了分布式领域里相较核心的一致性模型由紧到宽从常见的三种一致性模型到弱一致性模型的大家族再到最后的客户端一致性模型对“分布式一致性模型”这个话题展开了细致阐述而下一节内容则会一起聊聊分布式领域著名的一致性协议与算法如Paxos、Raft等我们下篇见~
