精华内容
下载资源
问答
  • 2022-02-07 00:17:43

    关于各种一致性的理解:
    1、数据一致性,往往指的是缓存和数据库的一致性。

    2、事务的一致性,和原子性类似,都是从一个状态变到另一个状态,但不同的是,原子性追求这个过程不能出错,不论结果对不对,不能出错。但一致性更追求结果一致,比如A减少100,B增加100,这是一致的。当A减少100,B增加60,这是原子的,但不是一致的。

    3、分布式事务的一致性:本质上来说,分布式事务就是为了保证在分布式场景下,数据操作的正确执行。但分布式事务不像本地事务,可以做到ACID,分布式事务做不到。比如分布式存储场景下,一个存储节点通过本地事务减少100,不能同时保证另一个存储节点事务增加100,这实际上就是数据不一致。而在本地事务中,是可以做到的,本地事务把减100和加100当作一个原子操作来执行。
    但是分布式事务也是可以解决这一类问题的,但从而带来了很高的代价,也就是我们说的CAP理论,P分区容错是一定的。那么当C很强时,也就是强一致性的时候,也就是说用户访问任何一台数据库服务器,必须都是要数据一致的,第一个存储节点减少100,另一个存储节点必须增加100,这就是强一致性,但是问题是有网络延迟,第一个节点减少了100,第二个还没来得及加100,此时用户要访问第二台数据库服务器,怎么办? 那就不让他访问,也就是吸收Availability可用性。那如果要保证可用性怎么办?那就牺牲一致性,数据不一致没关系,最终一致就可以了。

    那解决这样的问题的框架有哪些?比如seata的AT,TCC等,就是实现全局事务的统一提交,要么就不提交,那这样就能保证所有数据的一致了。但当全局事务没有统一提交的时候,可能用户的请求查数据库,可能查到的还是旧数据。

    4、分布式事务的原子性:单个分枝事务成功,但其他事务可能失败,需要全局回滚。

    5、注意:CAP理论强调的是说在分布式存储系统中的。

    以上纯属个人理解,有问题请指出探讨。

    参考:https://blog.csdn.net/yeyazhishang/article/details/80758354
    参考:https://segmentfault.com/a/1190000040321750
    参考:http://www.dockone.io/article/9804

    更多相关内容
  • 为了便于讨论问题,先简单介绍下数据一致性的基础理论。当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据...
  • 分布式系统数据一致性解决方案

    千次阅读 2022-03-03 21:10:14
    本文讨论的都是互联网企业在分布式架构下如何应对数据一致性问题的。 2.典型的一致性问题 案例1:下单和减库存的一致性 下单减库存有一致性的需求,如果下单了但是没减库存造成的结果是超卖;如果减库存了但下单...

    1.背景

    微服务架构是一把双刃剑,我们在享受微服务拆分带来好处的同时,势必会遇到数据模型和服务之间不一致的问题。本文讨论的都是互联网企业在分布式架构下如何应对数据一致性问题的。

    2.典型的一致性问题

    案例1:下单和减库存的一致性

    下单减库存有一致性的需求,如果下单了但是没减库存造成的结果是超卖;如果减库存了但下单失败会导致少卖。

    案例2:缓存和数据库的数据一致性

    电商系统一般会将热点数据缓存来减少数据库访问压力,这要求缓存和数据库数据是一致的,如果数据库数据发生变更但同步到缓存失败,这时就产生了缓存何数据库数据的不一致。

    案例3:两系统协调的一致性

    其实上面两个案例都可以归结为此案例,系统是上下游的关系,由于超时等原因可能导致两系统数据的状态不对。

    3.一致性理论

    ACID原理

    即关系型数据库的事务特性:原子性、一致性、隔离性和持久性。ACID这里不多说,一般核心交易系统都要有强一致性的事务要求,因此在做技术选型时,核心数据基本也只考虑关系型数据库。

    CAP原理

    CAP其实是一种权衡平衡的思想,用于指导在系统可用性设计、数据一致性设计时做权衡取舍。CAP,即一致性、可用性、分区容忍性。一致性强调在同一时刻副本一致,可用性指的是服务在有限的时间内完成处理并响应,分区容忍性说的是分布式系统本身的特点可以独立运行并提供服务。

    4.一致性协议

    说到一致性协议,大家肯定都听过两阶段协议协议、三阶段提交协议、Paxos协议、Raft协议等。这里我们简单比较一下。

    两阶段提交协议

    两阶段提交协议,顾名思义分两个阶段:准备阶段(投票反馈阶段)和 提交阶段(执行阶段)。准备阶段参与者在本地执行事务,在本地写redo\undo log,但不提交,有点万事俱备只欠东风的态势。提交阶段由协调者发出。

    两阶段协议提交存在的问题还挺多,具体包含:

    1. 阻塞问题,所有参与者必须收到协调者发起的指令才会提交,否则资源会被锁定,但由于不可靠的网络,协调者可能无法收到所有反馈,参与者也可能无法接收到指令。
    2. 单点故障,如果协调者宕机,参与者没有协调者指挥就会一致阻塞。
    3. 数据不一致,协调者发出的指令可能导致部分参与者收到,部分参与者由于网络原因未收到,有数据不一致的风险。

    三阶段提交协议

    针对两阶段提交的一些问题,三阶段提交做了一些改进,比如:

    1. 通过超时机制解决阻塞问题。
    2. 通过增加询问环节降低锁资源导致阻塞的概率。

    三阶段即canCommit、preCommit、doCommit。三阶段提交解决了资源阻塞问题,但仍然存在单点故障和数据不一致的问题。

    Raft投票协议

    前面说的两阶段提交协议和三阶段提交协议都存在单点问题和数据不一致的风险。为此Raft、Paxos、Zab使用的机制都是大多数的投票机制来解决单点问题和消灭不一致风险。我们以Raft协议来说,它分两个过程:

    1. Leader选举。
    2. 日志复制。

    首先,Leader选举是用于解决单点问题。一开始所有的节点都是追随者,当节点感知不到Leader存在时就会转变身份称为竞选者,为了防止出现多个竞选者竞争Leader的局面出现,每个节点都会等待一个随机时间才能称为竞选者。竞选者发起投票,当获得大多数同意反馈时则称为了Leader。Leader会定期对Follower发起心跳以通知自己的存活。通过心跳+投票机制防止了单点故障。

    然后,我们看看Raft是如何解决不一致问题的,这里使用到一个单调递增的序列号,通过序列号 + 多数投票机制保证数据一致性。

    Raft一致性原理可参考我原来写过的《全面理解Raft协议》一文。

    TCC

    TCC是互联网公司业务系统保证数据一致性的一种常见方法,它将任务拆分为Try、Confirm、Cancel三个过程,本质上Try、Confirm思想和两阶段是一致的,只是TCC增加了逆向过程,因此具有一定的修复能力。但TCC还是存在不一致的风险,面对这个问题,商业公司一般做法是保证最终一致,通过一些自动化补偿手段尽可能做到数据一致,且不用人工干预。

    小结:两阶段提交协议是所有一致性协议的基础,它是一个强一致性协议,但可用性太差;三阶段提交协议改善了两阶段提交协议,但还是为解决单点问题和存在不一致的风险;可靠的、强一致性协议最后是通过Raft、Paxos等投票协议做成的。一致性协议都有一个共同的问题,就是实现复杂,性能不好,更多用于HA组件,而非业务系统本身。

    5.最终一致性模式

    业务系统对一致性大多数情况没那么高,更多强调高可用,因此,多数业务系统强调最终一致性,这其实也是在CAP权衡下倾向于A。我们本节来分析一下最终一致性方案。最终一致性都强调写操作失败后进行补偿补救,常见的最终一致性有4种形态,我们依次分析分析。

    查询模式

    对于任何写操作,API设计时都要提供对应的查询或批量查询接口。如下图所示。

    如下订单操作

    interface OrderService {
     boolean submitOrder(int ticketId, OrderEntity order);
     Order queryOrder(int ticketId);
    }

    重试+逆向模式

    即当写操作失败了上游系统提供重试接口和逆向取消接口。上游系统需要保障重试写接口与逆向接口的幂等性。

    举例:

    interface OrderService {
     boolean submitOrder(int ticketId, OrderEntity order);
     boolean cancelOrder(int ticketId);
    }

    补救任务模式

    写操作失败后,同步创建补救任务,通过定时执行补救任务来达到最终一致。如果补救任务是一个消息通知型任务,有时会将写操作和通知任务放在一个事务中来保证写操作成功通知任务一定成功,并最终能够执行。

    异步消息模式

    该模式下通过消息队列来保证最终一致性,为了保证消息的可靠性,可以在业务系统发送消息前将写操作和消息持久化做成事务,然后异步通过消息队列中间件发送消息。该模式可能会出现重复消息,因此消息消费方需要保证幂等性。

    6.典型案例的一致性方案

    上一节我们已经讲过互联网公司在CA中倾向了高可用,选择了高可用最终一致性。因此典型案例的一致性方案不会是使用一致性协议的强一致性方案。

    案例1:下单和减库存的一致性

    由于允许短暂的不一致,因此库存接口可提供扣减写接口、查询接口以及逆向增接口。

    interface InventoryService {
     boolean deduct(int ticketId, int skuId);
     OpLog queryDeductLog(int ticketId);
     boolean cancelDeduct(int ticketId, int skuId);
    }

    客户端可通过“重试 + 逆向”模式同步方式进行一致性保证,也可以走异步补救任务或异步消息进行补救。

    电商平台还会采用一种更加严格的一致性手段,扣减库存分两个阶段:锁库存、确认减库存。为了保证失败后能够回滚还会解锁库存。扣减库存其实思想和两阶段提交是一样的,客户端其实就是协调者角色,客户端的可用性由系统监控告警和运维人员保障,参与者就是服务端,这里只有一个参与者。当然为了保证最终一致性还会有重试、逆向回滚以及异步补偿任务、异步消息等方式。

    案例2:缓存和数据库的数据一致性

    缓存是为了应对高并发的读请求,但当数据发生变更是需要将变化同步到缓存。

    首先,我们这里并不探讨强一致,因此在高并发时很短暂的不一致是可以接受的。因此先写数据库成功,但写缓存还未完成而操作从缓存读到旧数据这种情况是可以接受的。

    其次,我们简单说下是淘汰缓存还是更新缓存的问题,在两线程并发修改同一对象写入顺序不确认,采用更新缓存方式问题其实很多,因此我们就不自添烦恼了,淘汰缓存虽然可能造成一次mismatch,但其实还好。因此我们的结论是淘汰缓存。

    最后,我们探讨一次写数据库和缓存的先后顺序问题。由于写数据库和写数据库有一个先后顺序,这样就可能导致前一个写操作成功而后一个写操作失败的情况出现,不管是先写数据库先还是写缓存先,这种情况都会出现长时间不一致性的情况出现,因此需要处理这种异常情况。

    1. 淘汰缓存成功、写数据库失败

    其实这时一个伪问题,我们更新数据当然希望持久生效,所以如果先淘汰缓存,写数据库失败当然需要千方百计保证写数据库成功,如果网络本省就不可用怎么写都失败,这样就违背我们的初衷,因此很显然是必须先操作数据库而不是缓存。

    2.写数据库成功、淘汰缓存失败

    如果操作数据库成功,淘汰缓存失败导致缓存和数据库不一致,因此可以通过我们前面提到的补救措施,比如重试、补救任务、异步消息来保证最终一致性。关键还是变更的数据持久生效!!!

    小结:针对缓存和数据库一致性的策略是:先写数据库,再淘汰缓存。缓存和数据库的不一致可通过最终一致性模式解决。如果强一致性有要求,可将写数据库和淘汰缓存做到一个事务中,当淘汰缓存失败则回滚数据库变更,这样缓存和数据库数据还是一致的。

    总结

    本文较全面的分析了分布式系统的数据一致性模式。我们首先介绍了两个重要的原理:ACID和CAP,理解这两个原理对于理解事务和分布式事务很重要,读者朋友细细体会以下ACID的事务特征和CAP中CA的权衡思想。文章介绍了强一致性协议P:两阶段协议、三阶段协议和典型的投票协议。分布式架构下理解CAP很重要,目前互联网公司倾向于高可用最终一致性方案,本文介绍了4种常用的最终一致性模式,文章最后针对“下单和减库存”以及“缓存和数据库一致性”给出了解决方案,希望读者朋友看完之后有帮助。

    展开全文
  • 在大数据场景下,分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的“一致性”(Consistency)的保障,在分布式技术发展下,数据一致性解决方法和技术也...
  • 分布式技术发展下,数据一致性解决方法和技术也在不断的演进,本文就以分布式数据库作为案例,介绍分布式数据库数据一致性的原理以及实际实现。 1、数据一致性 1.1 数据一致性是什么 大部份使用传统关系型数据库...

    前言

    分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技术也在不断的演进,本文就以分布式数据库作为案例,介绍分布式数据库数据一致性的原理以及实际实现。

    1、数据一致性

    1.1 数据一致性是什么

    大部份使用传统关系型数据库的DBA在看到“数据一致性”时,第一反应可能都是数据在跨表事务中的数据一致性场景。但是本文介绍的“数据一致性”,指的是**“数据在多份副本中存储时,如何保障数据的一致性”**场景。

    由于在大数据领域,数据的安全不再由硬件来保证,而是通过软件手段,通过同时将数据写入到多个副本中,来确保数据的安全。数据库在同时向多个副本写入记录时,如何确保每个副本数据一致,称为“数据一致性”。

    1.2 关系型数据库如何保障数据一致性

    传统的关系型数据库对于运行环境–硬件要求都比较高,例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境,DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。所以在数据存储安全的技术要求下,传统关系型数据库更多是依赖硬件的技术来保障数据的安全性。

    在这里插入图片描述
    因为关系型数据库的数据安全是基于硬件来保障,并且数据也不会通过同时存储多份来保障数据的安全,所以关系型数据库的用户默认认为数据存储是一致的。

    1.3 分布式存储如何保障数据一致性

    本文在讨论分布式存储时,主要指的是大数据产品中的分布式文件系统和分布式数据库,例如:SequoiaDB和HDFS。

    用户在搞明白分布式存储的数据一致性原理时,必须要先明白为什么他们就需要数据一致性,和分布式存储的数据存储与关系型数据库的数据存储又有什么区别。

    大数据技术的诞生,确确实实让系统的性能有新的突破,并且支持硬件以水平扩展的方式来获得线性增长的性能和存储。这些都是过去传统关系型数据库所无法提供的。另外,大数据技术也抛弃了运行环境必须足够好的硬性要求,而是允许用户通过批量廉价X86服务器+本地磁盘的方式搭建规模集群,从而获得比过去依赖硬件垂直扩展所提供的更强的计算能力和更多的存储空间。

    大数据技术的核心思想就是分布式,将一个大的工作任务分解成多个小任务,然后通过分布式并发操作的方式将其完成,从而提高整个系统的计算效率或者是存储能力。而在分布式环境下,由于硬件的要求降低,必然需要大数据产品提供另外一个重要的功能–数据安全

    在这里插入图片描述
    大数据产品在解决数据安全的方式上,都比较接近,简单来说,就是让一份数据通过异步或者同步的方式保存在多台机器上,从而保障数据的安全。

    分布式存储在解决数据安全的技术难点后,又引入了一个新的技术问题,就是如何保障多个副本中的数据一致性。目前SequoiaDB是使用Raft算法来保证数据在多个副本中一致性。

    2、Raft算法

    2.1 Raft算法背景

    在分布式环境下,最著名的一致性算法应该是Paxos算法,但是由于它实在过于晦涩难懂,并且实现起来极度困难,所以在2013年,Diego Ongaro、John Ousterhout两个人以易懂(Understandability)为目标设计了一套一致性算法Raft。Raft算法最大的特点在于简单易懂,并且实现起来简单

    2.2 Raft算法概述

    与Paxos不同,Raft强调的是易懂,Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。

    众所周知当问题较为复杂时可以把问题分解为几个小问题来处理,Raft也使用了分而治之的思想。Raft算法重点解决三个子问题:选举(Leader election)、日志复制(Log replication)、安全性(Safety)。

    Raft算法强化了Leader节点的功能,Follower节点的数据只能够从Leader中获取,所以Follower节点的实现就变得简单,只要负责和Leader保持通信,并且接受Leader推送的数据即可。

    2.3 Raft算法原理

    2.3.1 节点角色

    Raft算法中,对节点的状态分为3种角色,分别是Leader(领导者)、Follower(追随者)和Candidate(候选者)。

    Leader,负责处理来自客户端的请求,负责将日志同步到Follower中,并且保证与Follower之间的heartBeat联系;

    Follower,当集群刚刚启动时,所有节点均为Follower状态,它的工作主要为响应Leader的日志同步请求,响应Candidate的请求,以及把请求到Follower的事务请求转发给Leader;

    Candidate,选举Leader时负责投票,选举出来Leader后,节点将从Candidate状态变为Leader状态。

    在这里插入图片描述

    2.3.2 Terms

    在分布式环境下,“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题,将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。

    Terms有以下原则

    • 每个Term中,至多存在一个Leader
    • 某些Term中,有可能存在由于选举失败,没有Leader的情况
    • 每个节点自己维护本地的currentTerm
    • 每个Term都是一个连续递增的编号
    • 如果Follower的Term编号比别的Follower Term编号小时,该Follower Term编号将更新Term编号,以保持与其他Follower Term编号一致

    2.3.3 选举

    Raft的选举由定时器触发,每个节点的触发时间都不相同。

    所有的节点在开始时状态都为Follower,当定时器触发选举后Term编号递增,该节点的状态由Follower转为Candidate,并且向其他节点发起RequestVote RPC请求,这时选举有3种情况可能发生:

    发起RequestVote的节点收到n/2+1(过半数)个节点的投票,该节点将从Candidate状态变为Leader状态,开始向其他节点发送HeartBeat以保持Leader的正常状态

    如果收到投票请求后,该节点发现发起投票的节点Term大于自己,则该节点状态从Candidate转为Follower,否则保持Candidate状态,并且拒绝该投票请求

    选举期间发生了超时,则Term编号递增,重新发起选举
    在这里插入图片描述

    2.3.4 日志复制

    日志复制主要的作用就是用来保证节点的数据一致性与高可用性。

    当Leader被选举出来后,所有的事务操作都必须要经过Leader处理。这些事务操作成功后,将会被按顺序写入到LOG中,每个LOG都包含一个index编号。

    Leader在LOG发生变化后,通过HeartBeat将新的LOG同步到Follower上,Follower在接收到LOG后,再向Leader发送ACK信息,当Leader接到大多数(2/n+1)Follower的ACK信息后,将该LOG设置为已提交,并且Leader将LOG追加到本地磁盘中。

    同时Leader将在下一个HeartBeat中,通知所有的Follower将该LOG存储在各自的本地磁盘中。

    2.3.5 安全性

    安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。

    如果当某个Follower在同步Leader的日志时失败,但是未来该Follower又可能被选举为Leader时,就有可能导致前一个Leader已经commit的日志发生覆盖,这样就导致了节点执行不同序列的日志。

    Raft的安全性就是用于保证选举出来的Leader一定包含先前已经commit LOG 的机制,主要遵循的原则如下:

    每个Term 只能选举一个Leader;

    Leader的日志完整性,则当Candidate重新选举Leader时,新的Leader必须要包含先前已经commit的LOG;

    Candidate在选举新的Leader时,使用Term来保证LOG的完整性;

    3、分布式数据库数据一致性技术实现

    以国产原厂的分布式数据库SequoiaDB为例,SequoiaDB在多副本的部署中,采用Raft算法保证数据在多副本环境中保持一致。

    SequoiaDB集群中,总共包含3中角色节点,分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据,所以只有编目节点和数据节点存在事务操作,换言之,编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。

    在这里插入图片描述

    3.1 编目节点和数据节点的事务日志介绍

    编目节点和数据节点由于都是需要存储数据的,并且在集群部署中该,为了确保数据的安全,都是建议采用分布式的方式进行部署,所以在数据同步中,需要采用Raft算法的基本原理进行数据同步。

    编目节点和数据节点在存储数据时,共包含两大部分,一个真实的数据文件,另一个是事务日志文件。
    在这里插入图片描述
    SequoiaDB的节点事务日志,默认情况下由20个64MB(总大小为1.25GB)的文件构成。节点的事务日志主要包含一个index编号和数据操作内容,index编号保持永远递增状态。

    另外,SequoiaDB节点的事务日志不会永久保存,而是当所有的事务日志写满后,再重新从第一个文件开始进行覆盖写入。

    3.2 编目分区组的数据一致性

    由于编目分区组是保存SequoiaDB集群的元信息,数据同步要求高,所以编目分区组的数据一致性要求为强一致性,即每次向编目分区组执行事务操作时,必须要确保所有的编目节点操作成功,才计算该操作执行成功,否则该事务操作将在整个编目分区组中回退事务日志,以保证分区组内的数据一致性。

    另外,编目分区组还有一个比较重要的特性,即编目分区组必须要存在主节点才能够正常工作,如果老的主节点宕机了,编目分区组暂时没有主节点,则该编目分区组不能够对外提供任何事务操作和数据查询操作。

    3.3 数据分区组的数据一致性

    数据分区组的数据一致性默认情况下为最终一致性性,即只要求主节点执行事务操作成功即视为操作成功,主节点将在未来异步同步ReplicaLOG到从节点上。

    3.4 主从节点的事务日志同步

    SequoiaDB的主从节点是通过事务日志同步来保证数据一致性的,并且主从节点的事务日志同步是单线程完成。

    如果当主节点和从节点的LSN差距为一条记录,则主节点会主动将最新的事务日志推送给从节点。

    如果主节点和从节点的LSN差距超过一条记录,则从节点会主动向主节点请求同步事务日志,主节点收到同步请求后,会将从节点的LSN号到主节点最新的LSN号对应的事务日志打包一次性发送给从节点。

    3.5 从节点日志重放

    当从节点获取到主节点推送过来的事务日志后,就会自动解析事务日志和重放。从节点在重放事务日志时,默认情况下会以10并发来重放事务日志。

    从节点在执行并发重放日志时有条件限制,即在集合的唯一索引个数<=1的情况下,INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、LOB REMOVE操作可以支持并发重放事务日志。从节点在做并发重放时,是通过记录的OID进行打散并发执行,这样就可以保证对相同记录的操作不会由于并发重放导致数据不一致。

    但是用户需要注意,从节点在重放事务日志时, DROP CL操作不能够支持并发重放。

    4、SequoiaDB数据一致性应用

    目前SequoiaDB数据分区组的数据一致性是基于集合级别进行配置的。用户在使用SequoiaDB过程中,可以随时调整数据一致性的强度。

    4.1 创建集合时指定

    在一个多副本的SequoiaDB集群中,集合默认的数据一致性行级别为“最终一致性”。用户可以在创建集合时显式指定该集合的“数据一致性强度”,例如可以在SequoiaDB Shell中执行以下命令

    db.CSNAME.createCL(“CLNAME”,{ReplSize:3})

    ReplSize参数填写范围
    在这里插入图片描述

    4.2 修改已经存在的集合

    如果集合在创建时没有设置“数据一致性”ReplSize参数,用户也可以对已经存在的集合进行修改,在SequoiaDB Shell修改命令如下

    db.CSNAME.CLNAME.alter({ReplSize:3})

    ReplSize的取值范围和创建集合时一致。

    4.3 如何查看集合的ReplSize参数

    如果用户希望检查当前集合的RepliSize参数值,可以通过数据库快照进行查看,在SequoiaDB Shell查看命令如下

    db.snapshot(SDB_SNAP_CATALOG,{}, {“Name”:null, “IsMainCL”:null,“MainCLName”:null, “ReplSize”:null})
    打印信息如下

    {

    “MainCLName”:“test.main2”,

    “Name”: “foo.bar2”,

    “IsMainCL”: null,

    “ReplSize”: null

    }

    {

    “IsMainCL”: true,

    “Name”: “test.main2”,

    “MainCLName”: null,

    “ReplSize”: null

    }

    {

    “Name”: “foo.tt”,

    “ReplSize”: 3,

    “IsMainCL”: null,

    “MainCLName”: null

    }

    5、总结

    分布式的数据库,通过Raft算法来确保在分布式情况上数据的一致性,并且编目分区组和数据分区组对数据一致性要求又有所不同,编目分区组始终要求的是数据在多副本请情况下数据强一致性,而数据分区组则可以由用户在创建集合时来执行数据一致性的强度,强度越高,数据安全性越好,但是执行的效率就会相对较差,反之依然。

    目前SequoiaDB在数据一致性场景上,用户的调整空间较大,可以根据不同的业务要求来调整数据一致性的强度,以满足业务或追求性能最优,或者数据最安全的技术要求。

    展开全文
  • 分布式系统:数据一致性解决方案

    千次阅读 2020-12-14 23:02:27
    点击上方蓝色字体,选择“设为星标”回复”资源“获取更多资源大数据技术与架构点击右侧关注,大数据开发领域最强公众号!大数据真好玩点击右侧关注,大数据真好玩!在分布式系统中,随着系统架构演进...

    点击上方蓝色字体,选择“设为星标

    回复”资源“获取更多资源

    大数据技术与架构

    点击右侧关注,大数据开发领域最强公众号!

    大数据真好玩

    点击右侧关注,大数据真好玩!

    在分布式系统中,随着系统架构演进,原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题,但业务实际又需要保障一致性,下面我从学习和实战运用总结一下分布式一致性解决方案。

    1. CAP & Base理论

    

    CAP定理指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。这三个要素最多只能同时实现两点,不可能三者兼顾:

    • 一致性:在分布式系统中的所有数据备份,在同一时刻是否同样的值。

    • 分区容错性:可靠性,无论应用程序或系统发生错误,还是用户以意外或错误的方式使用,软件系统都能继续运行。

    • 可用性:在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。

    

    

    CAP理论3选2是伪命题,实际上必须从A和C选择一个和P组合,更进一步基本上都会选择A,相比一致性,系统一旦不可用或不可靠都可能会造成整个站点崩溃,所以一般都会选择AP。但是不一致的问题也不能忽略,使用最终一致是比较好的办法。

    

    BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结, 是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素:

    • 基本可用(Basically Available):基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性。注意,这绝不等价于系统不可用。比如:

      • 响应时间上的损失。正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障,查询结果的响应时间增加了1~2秒

      • 系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。

    • 软状态(Soft State):软状态指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

    • 最终一致(Eventually Consistent):最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

    

    最终一致的核心做法就是通过记录对应操作并在操作失败时不断进行重试直到成功为止。

    2. 重试

    在出现一致性问题时如果系统的并发或不一致情况较少,可以先使用重试来解决。

    

    在调用Service B超时或失败时进行重试:

    • 同步调用,捕获异常重新调用Service B。

    • 异步消息,捕获异常发送延迟消息重新调用Service B。

    • 异步线程,捕获异常开启异步线程重新调用Service B。

    

    如果重试还是不能解决问题,那么需要使用分布式事务来解决。

    3. 分布式事务

    对于分布式一致性问题可以采用分布式事务来解决。

    3.1 2PC-XA协议

    XA事务由一个或多个资源管理器(Resource Managers)、一个事务管理器(Transaction Manager)以及一个应用程序(Application Program)组成。

    • 资源管理器(RM):参与者。提供访问事务资源的方法。通常一个数据库就是一个资源管理器。

    • 事务管理器(TM):协调者。分配标识符,监视事务的进度,并负责事务完成和故障恢复。

    • 应用程序(AP):发起者。定义事务的边界,制定全局事务中的操作。

    

    整个过程分为2个阶段:准备(prepare)和提交(commit),prepare前需要先执行对应的DML操作。

    

    

    Mysql XA事务语句:

    
    
    注:执行前需要先生成全局唯一的xid
    
    
    XA {START|BEGIN} xid [JOIN|RESUME]
    DML操作
    XA END xid [SUSPEND [FOR MIGRATE]]
    XA PREPARE xid //1.准备
    XA COMMIT xid [ONE PHASE] //2.提交
    XA ROLLBACK xid
    XA RECOVER
    

    简单的事例:

    
    
    //准备前阶段
    mysql> XA START 'xatest';
    Query OK, 0 rows affected (0.00 sec)
    
    
    mysql> INSERT INTO mytable (i) VALUES(10);
    Query OK, 1 row affected (0.04 sec)
    
    
    mysql> XA END 'xatest';
    Query OK, 0 rows affected (0.00 sec)
    //准备
    mysql> XA PREPARE 'xatest';
    Query OK, 0 rows affected (0.00 sec)
    //提交
    mysql> XA COMMIT 'xatest';
    Query OK, 0 rows affected (0.00 sec)
    

    XA看起来很美好,但还是存在一些问题:

    • commit丢失/超时导致数据不一致。A commit成功,B commit时网络超时导致数据库未收到commit请求。

    • 性能低。所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态。

    • 主备数据不一致。

    • 协调者单点故障,在任意阶段协调者发生故障都会导致分布式事务无法进行。

    

    3.2 3PC

    3PC通过在参与者加入超时机制解决2PC中的协调者单点带来的事务无法进行的问题,但是性能和一致性仍没有解决。

    

    3.3 TCC

    

    这样看下来强一致是很难做了,还是最终一致把。。。

    

    TCC是通过最终一致来达到分布式事务的效果,即:在短时间内无法保证一致性,但最终会一致。核心分为2个阶段:1.Try  2.Confirm or Cancel。先尝试(Try)操作数据,如果都成功则全部确认(Confirm)该修改,如果有任意一个尝试失败,则全部取消(Cancel)。简单点说就是增加了中间态和可回改能力。

    

    

    通过重试机制保障Confirm和Cancel一定能成功。TCC解决了性能问题,但是业务系统想要实现对业务代码的侵入性很大,可以学习一下阿里GTS是如何做的。

    

    3.4 事务管理器

    在实际运用中事务管理器(TM)一般是由应用程序(AP)兼职实现的,这样对业务代码侵入性大,最好是把TM做成中间层。接下来详细看一下TM的职责:协调者。分配标识符,监视事务的进度,并负责事务完成和故障恢复。TM需要具备持久化能力才能完成监控、故障恢复和协调,整个协调过程可以分为3个阶段:

    • 准备阶段:向TM注册全局事务并获取到全局唯一XID,这一步需要定义好事务的范围。

    • 执行阶段:应用程序AP执行业务功能操作自己的RM,全部执行完毕后向TM commit,如果无失败则整个事务成功。

    • 确认/回滚阶段:如果第2步出现异常会触发该阶段,TM咨询各个AP对应操作是否成功,如果成功则commit,如果失败则调用AP进行rollback。

    

    下面简单介绍几种实现方式。

    3.4.1 本地事务管理器

    对于简单的业务可能只要保障2个数据库之间的一致,这样在本地实现事务管理器比较快成本也不高。

    

    

    1. 1. 在做业务逻辑之前把对应事件添加到本地event表中(记录订正时所需要的关键数据)

    2. 2. 执行业务逻辑

    3. 1.本地业务逻辑,操作表数据等等

    4. 2.RPC调用其他服务

    5. 3.修改event状态为确认

    6. 4. 如果第2步不成功,则event状态还是预提交,通过定时任务捞取再执行订正逻辑

    7. 5. 检查业务逻辑中的操作是否完成,如未完成则执行订正逻辑

    8. 1.本地业务逻辑是否执行成功

    9. 2.RPC调用其他服务是否执行成功

    10. 6.返回订正结果

    11. 1.成功则修改event为确认提交

    12. 2.未成功则不操作,等待轮询订正

    3.4.2 外部事务管理器

    阿里GTS:https://help.aliyun.com/document_detail/157850.html

    3.5 DB和MQ之间的一致性

    

    在实际场景中,业务系统对本地DB数据变更后会广播对应的消息,消费者消费消息做自己的业务逻辑,按正常逻辑消息会在数据库变更后发出,如果消息发送超时且失败那么DB和MQ之间就产生了不一致问题,如何解决呢?使用可靠消息来解决,核心逻辑保证消息从投递到消费的过程中不会丢失:生产者confirm、消费者ack和持久化。理论上只要使用生产者确认机制即可,但是不使用消费者ack则没有意义。消费者需要开启手动ack同时做到幂等消费,MQ需要通过将exchange、queue和message进行持久化来保证消息不丢失,生产者则需要通过确认机制保证消息一定投递到MQ种,接下来重点讲解一下生产者确认机制。

    

    confirm机制是在消息投递到所有匹配的queue之后发送确认消息给生产者,这样生产者就知道消息投递成功,但是由于消息是在DB操作之后发出的,生产者必须增加记录表来记录消息投递状态,如果投递成功就在收到确认消息时把记录标记为投递成功,如果长时间未收到确认消息则大概率是消息丢失了,再定时重新投递,这样就可以保证消息最终一定能投递成功。核心逻辑其实就是通过全局事务ID来标识DB操作和MQ消息是在一个分布式事务中的。

    

    疑点:在学习RabbitMQ confirm机制时发现生产者接收到的确认消息只有消息ID,这个消息ID不能作为全局事务ID,所以无法解决DB和MQ之间的一致性问题,后续再看看其它MQ产品是怎么做的。

    

    上面的方式需要业务系统维护消息状态,这部分可以交给中间件来实现,实现逻辑会变得不一样。

    

    

    预投递的消息不会分发到queue中,只有在接收到确认投递的请求后才会进行投递,如果确认操作因为网络异常失败了,MQ在过一段时间之后主动询问业务系统该消息是否可投递(失败不断重试),这样就能在异常时做到最终一致,不过依赖MQ产品的能力。

    3.6 DB和缓存之间的一致性

    DB和缓存之间同样也存在不一致问题,先写DB再写缓存如果缓存写失败就不一致了,同样的需要重试更新缓存来做最终一致。方法可以参考“2.重试”部分,如果一定要保证重试不丢失可以用可靠消息或本地task表来记录重试操作,有条件的可以使用DB DRC消息对业务的侵入会小一些。需要注意的是同步更新和异步更新同时使用时可能会产生更新覆盖的问题,加上毫秒级的时间戳或版本号来丢弃旧的更新。

    4. 兜底核对

    虽然有了分布式事务,但是在实际场景中可能会因为bug导致数据不一致,这时需要兜底来做最后一道防线,通过定时核对数据是否一致,如不一致手动/自动进行订正。

    4.1 系统自核对

    如果系统数量和数据量不多的情况下可以由业务系统自行核对,通过发送延迟消息自消费或监听其他系统消息做相关数据核对并进行订正。

    

    4.2 搭建核对系统

    在核对工作繁多的情况下,由业务系统自己核对会存在很多耦合,这时可以选择搭建独立的核对系统进行核对和订正。

    

    1.监听drc消息

    

    

    2.监听业务消息

    

    参考:

    • 阿里GTS:https://help.aliyun.com/document_detail/157850.html?spm=a2c4g.11186623.6.554.47ae4df4Zy6hBI

    • 饿了么DRC:https://zhuanlan.zhihu.com/p/34958596

    • Mysql XA:https://dev.mysql.com/doc/refman/8.0/en/xa-statements.html

    版权声明:

    本文为大数据技术与架构整理,原作者独家授权。未经原作者允许转载追究侵权责任。

    编辑|冷眼丶

    微信公众号|import_bigdata

    欢迎点赞+收藏+转发朋友圈素质三连

    文章不错?点个【在看】吧! ????

    展开全文
  • 分布式事务数据一致性解决方案

    千次阅读 2020-09-03 01:01:53
    2PC 两阶段提交 由一个事务协调器器去通知各事务执行者准备事务、提交或回滚事务,它解决数据一致性问题,但是通信时间、资源锁定时间太长,系统的可用性受到影响 利用RocketMq的消息事务机制,将生产者本地...
  • 保证分布式数据一致性的6种方案

    万次阅读 2018-07-30 17:17:07
    在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据一致性?  具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;要么同时失败。A、B、C 可能是多...
  • 分布式缓存一致性问题解决方案

    千次阅读 2020-08-22 21:27:03
    该文章主要是来自于通用配置系统使用了文件缓存作为二级缓存,他的一致性如果保证的问题,目前了解到的有三种...1.分布式缓存的一致性问题 2.聊聊轻量级本地缓存设计 3.缓存同步、如何保证缓存一致性、缓存误用 ...
  • 解决分布式系统一致性的问题

    千次阅读 2019-04-26 23:15:26
    一致性 随着公司的访问量增加,不但要求对用户的响应速度快,还要求吞吐量的指标向外扩展(即水平伸缩)。于是单节点的服务器已经无法满足需求,又随着人员的增多以及项目的多职责,于是我们谈论最多的话题就是拆分。...
  • 并给出RocketMQ实现方式及原理,实验表明事务型消息可以较好解决分布式数据一致性问题,最后分析了上述方法的优缺点,本文提出的在分布式微服务构建中数据一致性处理方法应用中具有一定的借鉴作用.
  • 细说分布式下的数据一致性

    万次阅读 2018-08-29 11:21:47
    细说分布式下的数据一致性 名词解释 强一致性 最终一致性 XA事物 JDBC事物、JTA事物 TCC 产生场景 单一数据库、单一系统无法支撑业务和数据的增长而出现拆分化的演进,数据存储于不同的事物管理单元但又要...
  • 如何可靠保存凭证(消息) 有两种方法:业务与消息耦合的方式 支付宝在完成扣款的同时,同时记录消息数据,这个消息数据与业务数据保存在同一数据库实例里(消息记录表表名为message);12345Begin transaction ...
  • 怎么解决分布式场景下数据一致性 问题 ,暂且用 分布式事务 来定义吧。 同样的问题还存在于其他的场景: 送礼: 调用支付服务:先扣送礼用户的金币,然后给主播加相应的荔枝 确认第一步成功后...
  • 分布式缓存一致性(Redis、MySQL)

    千次阅读 2020-07-20 01:14:05
    文章目录分布式——缓存一致性(Redis、MySQL)1. 前言2. 常见方案的问题点2.1 先更新数据库,再更新缓存2.2 先删除缓存,再更新数据库2.3 先更新...分布式一致性的问题,既是指“如何保证分布式多个节点的数据一样、
  • 分布式系统中的一致性模型

    千次阅读 2022-04-15 09:30:34
    一致性模型本质上是进程与数据存储的约定:如果进程遵循某些规则,那么进程对数据的读写操作都是可预期的。
  • 如何保证分布式系统数据一致性

    万次阅读 多人点赞 2018-12-24 10:26:05
    面试的时候,有面试官问到:选取你比较熟悉的项目,谈谈如何在做容灾负载的时候数据一致性问题,具体点比如你里面的派单,如何保证一个司机不在同一时间内接到两个订单,然后保证实时性?  一般的解决方案是在派单...
  • 分布式系统数据一致性介绍.docx
  • 这是一个开撕的话题,我经历过太多的关于分布式事务的需求:“有没有简单的方案,像使用数据库事务那样,解决分布式数据一致性的问题”。特别是微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来...
  • 我们综合对比下几种分布式事务解决方案: 一致性保证:XA > TCC = SAGA > 事务消息 业务友好性:XA > 事务消息 > SAGA > TCC 性 能 损 耗:XA > TCC > SAGA = 事务消息 整体上了解了一个分布式事务框架的原理和实现...
  • 分布式存储数据一致性技术架构.docx
  • 分布式系统:数据一致性解决方案.docx
  • 近日,腾讯云发布了分布式数据库解决方案(DCDB),其最明显的特性之一就是提供了高于开源分布式事务XA的...虽然分布式数据库能解决性能难题,但事务一致性(Consistency)的问题,却很难在分布式数据库上得到解决
  • 分布式系统的一致性问题(汇总)

    万次阅读 多人点赞 2019-09-02 15:32:19
    保证分布式系统数据一致性的6种方案 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要...
  • 文章目录一、写在前面的话二、数据库的事务三、分布式环境的各种问题三、CAP和BASE理论四、一致性协议(1)两阶段提交(2)三阶段提交(3)Paxos算法五、写在最后的话 一、写在前面的话 在分布式来临之前,主流是...
  • 微服务下数据一致性的特点,总结了下目前的保障微服务下数据一致性的几种实现方式如下,以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍,并未深入展开,具体的实现方式本人也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 262,941
精华内容 105,176
关键字:

怎么解决分布式数据一致性