如何保障微服务架构下的数据一致性

一、微服务架构的数据一致性问题数据库

以电商平台为例,当用户下单并支付后,系统须要修改订单的状态而且增长用户积分。因为系统采用的是微服务架构,分离出了支付服务、订单服务和积分服务,每一个服务都有独立数据库作数据存储。当用户支付成功后,不管是修改订单状态失败仍是增长积分失败,都会形成数据的不一致。网络

为了解决例子中的数据一致性问题,一个最直接的办法就是考虑数据的强一致性。那么如何保证数据的强一致性呢?咱们从关系型数据库的 ACID 理论提及。架构

关系型数据库具备解决复琐事务场景的能力,关系型数据库的事务知足 ACID 的特性。并发

 

  • Atomicity:原子性(要么都作,要么都不作)框架

  • Consistency:一致性(数据库只有一个状态,不存在未肯定状态)分布式

  • Isolation:隔离性(事务之间互不干扰)微服务

  • Durability: 永久性(事务一旦提交,数据库记录永久不变)高并发

 

具备 ACID 特性的数据库支持数据的强一致性,保证了数据自己不会出现不一致。性能

然而微服务架构下,每一个微服务都有本身的数据库,致使微服务架构的系统不能简单地知足 ACID,咱们就须要寻找微服务架构下的数据一致性解决方案。3d

微服务架构的系统自己是一种分布式系统,而本文讨论的问题其实也就是分布式事务之数据一致性的问题,咱们来聊聊分布式系统的 CAP 理论和 BASE 理论。

CAP 是指在一个分布式系统下, 包含三个要素:Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),而且三者不可得兼。

 

  • C:Consistency,一致性,全部数据变更都是同步的。

  • A:Availability,可用性,即在能够接受的时间范围内正确地响应用户请求。

  • P:Partition tolerance,分区容错性,即某节点或网络分区故障时,系统仍可以提供知足一致性和可用性的服务。

 

关系型数据库 单节点 保证了数据强一致性(C)和可用性(A),可是却没法保证分区容错性(P)。

然而在分布式系统下,为了保证模块的分区容错性(P),只能在数据强一致性(C)和可用性(A)之间作平衡。具体表现为在必定时间内,可能模块之间数据是不一致的,可是经过自动或手动补偿后可以达到最终的一致。

BASE 理论主要是解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题。BASE 理论包含如下三个要素:

 

  • BA:Basically Available,基本可用。

  • S:Soft State,软状态,状态能够有一段时间不一样步。

  • E:Eventually Consistent,最终一致,最终数据是一致的就能够了,而不是时时保持强一致。

 

BASE 模型与 ACID 不一样,知足 CAP 理论,经过 牺牲强一致性来保证系统可用性。因为牺牲了强一致性,系统在处理请求的过程当中,数据能够存在短时的不一致。

系统在处理业务时,记录每一步的临时状态。当出现异常时,根据状态判断是否继续处理请求或者退回原始状态,从而达到数据的最终一致。

例如,在上面的案例中,支付成功,订单也成功,但增长积分失败,此时,不该回滚支付和订单,而应经过一些 补偿方法 来让积分得以正确地增长。后面会讲到具体的实现方法。

在分享咱们的分布式事务实践方案以前,先看看早期解决分布式事务问题的二阶段提交协议。

二、二阶段提交协议

 

X/Open DTP(Distributed Transaction Process)是一个分布式事务模型,此模型主要使用二阶段提交(2PC,Two-Phase-Commit)来保证分布式事务的完整性。在这个模型里面,有三个角色:

  • AP:Application,应用程序,业务层。

  • RM:Resource Manager,资源管理器,关系型数据库或支持 XA 接口(XA 规范是 X/Open 组织定义的分布式事务规范)的组件。

  • TM: Transaction Manager ,事务管理器,负责各个 RM 的提交和回滚。

当应用程序(AP)调用了事务管理器(TM)的提交方法时,事务的提交分为两个阶段实行。

2.一、第一阶段(准备阶段)

 

TM 通知全部参与事务的各个 RM,给每一个 RM 发送 prepare 消息。

RM 接收到消息后进入准备阶段后,要么直接返回失败,要么建立并执行本地事务,写本地事务日志(redo 和 undo 日志),可是 不提交(此处只保留最后一步耗时最少的提交操做给第二阶段执行)。

2.二、第二阶段(提交 / 回滚阶段)

 

TM 收到 RM 准备阶段的失败消息或者获取 RM 返回消息超时,则直接给 RM 发送回滚(rollback)消息,不然发送提交(commit)消息。

RM 根据 TM 的指令执行提交或者回滚,执行完成后释放全部事务处理过程当中使用的锁(最后阶段释放锁)。

 

2.三、二阶段提交的利弊

 

优势

2PC 提供了一套完整的分布式事务的解决方案,遵循事务严格的 ACID 特性。

缺点

  • TM 经过 XA 接口与各个 RM 之间进行数据交互,从第一阶段的准备阶段,业务所涉及的数据就被锁定,而且锁定跨越整个提交流程。在高并发和涉及业务模块较多的状况下对数据库的性能影响较大。

  • 二阶段是 反可伸缩模式 的,业务规模越大,涉及模块越多,局限性越大,系统可伸缩性越差。

  • 在技术栈比较杂的分布式应用中,存储组件有不少 不支持 XA 协议。

二阶段的诸多弊端,致使分布式系统下没法直接使用此方案来解决数据一致性问题,但它提供了解决分布式系统下数据一致性问题的思路。。

下面就经过案例来分享咱们是如何保证微服务架构的数据一致性的。

三、可靠消息最终一致性

可靠消息最终一致性方案本质上是 利用 MQ 组件实现的二阶段提交。此方案涉及 3 个模块:

 

  • 上游应用,执行业务并发送 MQ 消息。

  • 可靠消息服务和 MQ 消息组件,协调上下游消息的传递,并确保上下游数据的一致性。

  • 下游应用,监听 MQ 的消息并执行自身业务。

 
3.一、上游应用执行业务并发送 MQ 消息(第一阶段)

上游应用将本地业务执行和消息发送绑定在同一个本地事务中,保证要么本地操做成功并发送 MQ 消息,要么两步操做都失败并回滚。

上游应用和可靠消息之间的业务交互图以下:



  1. 上游应用发送待确认消息到可靠消息系统

  2. 可靠消息系统保存待确认消息并返回

  3. 上游应用执行本地业务

  4. 上游应用通知可靠消息系统确认业务已执行并发送消息。

  5. 可靠消息系统修改消息状态为发送状态并将消息投递到 MQ 中间件。

以上每一步均可能出现失败状况,分析一下这 5 步出现异常后上游业务和消息发送是否一致:

 
上游应用执行完成,下游应用还没有执行或执行失败时,此事务即处于 BASE 理论的 Soft State 状态。
 
3.二、下游应用监听 MQ 消息并执行业务(第二阶段)

下游应用监听 MQ 消息并执行业务,而且将消息的消费结果通知可靠消息服务。

可靠消息的状态须要和下游应用的业务执行保持一致,可靠消息状态不是已完成时,确保下游应用未执行,可靠消息状态是已完成时,确保下游应用已执行。

下游应用和可靠消息服务之间的交互图以下:

  1. 下游应用监听 MQ 消息组件并获取消息

  2. 下游应用根据 MQ 消息体信息处理本地业务

  3. 下游应用向 MQ 组件自动发送 ACK 确认消息被消费

  4. 下游应用通知可靠消息系统消息被成功消费,可靠消息将该消息状态更改成已完成。

以上每一步均可能出现失败状况,分析一下这 4 步出现异常后下游业务和消息状态是否一致:

经过分析以上两个阶段可能失败的状况,为了确保上下游数据的最终一致性,在可靠消息系统中,须要开发 消息状态确认 和 消息重发 两个功能以实现 BASE 理论的 Eventually Consistent特性。
 
3.三、消息状态确认

可靠消息服务定时监听消息的状态,若是存在状态为待确认而且超时的消息,则表示上游应用和可靠消息交互中的步骤 4 或者 5 出现异常。

可靠消息则携带消息体内的信息向上游应用发起请求查询该业务是否已执行。上游应用提供一个可查询接口供可靠消息追溯业务执行状态,若是业务执行成功则更改消息状态为已发送,不然删除此消息确保数据一致。具体流程以下:

  1. 可靠消息查询超时的待确认状态的消息

  2. 向上游应用查询业务执行的状况

  3. 业务未执行,则删除该消息,保证业务和可靠消息服务的一致性。业务已执行,则修改消息状态为已发送,并发送消息到 MQ 组件。

3.四、消息重发

消息已发送则表示上游应用已经执行,接下来则确保下游应用也能正常执行。

可靠消息服务发现可靠消息服务中存在消息状态为已发送而且超时的消息,则表示可靠消息服务和下游应用中存在异常的步骤,不管哪一个步骤出现异常,可靠消息服务都将此消息从新投递到 MQ 组件中供下游应用监听。

下游应用监听到此消息后,在保证幂等性的状况下从新执行业务并通知可靠消息服务此消息已经成功消费,最终确保上游应用、下游应用的数据最终一致性。具体流程以下:

  1. 可靠消息服务定时查询状态为已发送并超时的消息

  2. 可靠消息将消息从新投递到 MQ 组件中

  3. 下游应用监听消息,在知足幂等性的条件下,从新执行业务。

  4. 下游应用通知可靠消息服务该消息已经成功消费。

经过消息状态确认和消息重发两个功能,能够确保上游应用、可靠消息服务和下游应用数据的最终一致性。

固然在实际接入过程当中,须要引入 人工干预 功能。好比引入重发次数限制,超太重发次数限制的将消息修改成死亡消息,等待人工干预。

代入开篇案例,经过可靠消息最终一致性方案,第一阶段,订单状态更改以前,订单服务向可靠消息服务请求保存待确认消息。可靠消息服务保存消息并返回。

订单服务接收到返回信息后执行本地业务并通知可靠消息服务业务已执行。消息服务更改消息状态并将消息投递到 MQ 中间件。

第二阶段,积分系统监听到 MQ 消息,查看积分是否已增长,若是没有增长则修改积分,而后请求可靠消息服务。可靠消息服务接收到积分系统的请求,将消息状态更改成已完成。

到这里,已经介绍完如何经过可靠消息服务来保证数据的一致性。但因为引入了可靠消息服务和消息队列,带来了必定的 复杂性,因此,它更 适用于跨平台技术栈不统一的场景。

下面再来介绍在技术栈统一的状况下,如何经过 TCC 来解决数据一致的方法。

四、TCC(Try-Confirm-Cancel)

TCC 方案是二阶段提交的 另外一种实现方式,它涉及 3 个模块,主业务、从业务 和 活动管理器(协做者)。

下面这张图是互联网上关于 TCC 比较经典的图示:

 

第一阶段:主业务服务分别调用全部从业务服务的 try 操做,并在活动管理器中记录全部从业务服务。当全部从业务服务 try 成功或者某个从业务服务 try 失败时,进入第二阶段。

第二阶段:活动管理器根据第一阶段从业务服务的 try 结果来执行 confirm 或 cancel 操做。若是第一阶段全部从业务服务都 try 成功,则协做者调用全部从业务服务的 confirm 操做,不然,调用全部从业务服务的 cancel 操做。

在第二阶段中,confirm 和 cancel 一样存在失败状况,因此须要对这两种状况作 异常处理 以保证数据一致性。

  1. Confirm 失败:则回滚全部 confirm 操做并执行 cancel 操做。

  2. Cancel 失败:从业务服务须要提供自动 cancel 机制,以保证 cancel 成功。

目前有不少基于 RPC 的 TCC 框架,可是不适用于微服务架构下基于 HTTP 协议的交互模式。咱们此次只讨论基于 HTTP 协议的 TCC 实现。具体的实现流程以下:


 

  1. 主业务服务调用从业务服务的 try 操做,并获取 confirm/cancel 接口和超时时间。

  2. 若是从业务都 try 成功,主业务服务执行本地业务,并将获取的 confirm/cancel 接口发送给活动管理器,活动管理器会顺序调用从业务 1 和从业务 2 的 confirm 接口并记录请求状态,若是请求成功,则通知主业务服务提交本地事务。若是 confirm 部分失败,则活动管理器会顺序调用从业务 1 和从业务 2 的 cancel 接口来取消 try 的操做。

  3. 若是从业务部分或所有 try 失败,则主业务直接回滚并结束,而 try 成功的从业务服务则经过定时任务来处理处于 try 完成但超时的数据,将这些数据作回滚处理保证主业务服务和从业务服务的数据一致。

 

代入开篇提到的案例,经过 TCC 方案,订单服务在订单状态修改以前执行预增积分操做(try),并从积分服务获取 confirm/cancel 预增积分的请求地址。

若是预增积分(try)成功,则订单服务更改订单状态并通知活动管理器,活动管理器请求积分模块的 confirm 接口来增长积分。

若是预增积分(try)失败,则订单服务业务回滚。积分服务经过定时任务删除预增积分(try)超时的数据。

另外若是活动管理器调用积分服务的 confirm 接口失败,则活动管理器调用积分服务 cancel 接口来取消预增积分,从而,保证订单和积分数据的最终一致性。

经过上面的对可靠消息服务和 TCC 方案的描述,咱们 解决了技术栈一致和不一致的两种状况下的数据一致性问题。

可是,一般在这些核心业务上有 不少附加业务,好比当用户支付完成后,须要经过短信通知用户支付成功。

这一类业务的成功或者失败不会影响核心业务,甚至不少大型互联网平台在并高并发的状况下会主动关闭这一类业务以保证核心业务的顺利执行。那么怎么处理这类状况呢,咱们来看看最大努力通知方案。

五、最大努力通知

最大努力通知方案涉及三个模块:

 

  • 上游应用,发消息到 MQ 队列。

  • 下游应用(例如短信服务、邮件服务),接受请求,并返回通知结果。

  • 最大努力通知服务,监听消息队列,将消息存储到数据库中,并按照通知规则调用下游应用的发送通知接口。

 

具体流程以下:


 

  1. 上游应用发送 MQ 消息到 MQ 组件内,消息内包含通知规则和通知地址

  2. 最大努力通知服务监听到 MQ 内的消息,解析通知规则并放入延时队列等待触发通知

  3. 最大努力通知服务调用下游的通知地址,若是调用成功,则该消息标记为通知成功,若是失败则在知足通知规则(例如 5 分钟发一次,共发送 10 次)的状况下从新放入延时队列等待下次触发。

 

最大努力通知服务表示在 不影响主业务 的状况下,尽量地确保数据的一致性。它须要开发人员根据业务来指定通知规则,在知足通知规则的前提下,尽量的确保数据的一致,以尽到最大努力的目的。

根据不一样的业务能够定制不一样的通知规则,好比通知支付结果等相对严谨的业务,能够将通知频率设置高一些,通知时间长一些,好比隔 5 分钟通知一次,持续时间 1 小时。

若是不重要的业务,好比通知用户积分增长,则能够将通知频率设置低一些,时间短一些,好比 10 分钟通知一次,持续 30 分钟。

代入上面提到的支付成功短信通知用户的案例,经过最大努力通知方案,当支付成功后,将消息发送到 MQ 中间件,在消息中,定义发送规则为 5 分钟一次,最大发送数为 10 次。

最大努力通知服务监听 MQ 消息并根据规则调用消息通知服务(短信服务)的消息发送接口,并记录每次调用的日志信息。在通知成功或者已通知 10 次时,中止通知。

六、总   结

上面经过案例详细介绍了咱们解决微服务之间数据不一致问题的三种方案,下面经过一张简单的对比图,为你们选择合适的解决方案提供简单依据。

相关文章
相关标签/搜索