您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

微服务进阶场景实战:最终一致性与实时一致性解决方案如何设计?

时间:2022-10-23 12:21:19  来源:  作者:互联共商

数据一致性

前面总结了微服务的9个痛点,有些痛点没有好的解决方案,而有些痛点是有对策的,从本章开始,就来讲解某些痛点对应的解决方案。

这一章先解决数据一致性的问题,先来看一个实际的业务场景。

业务场景:下游服务失败后上游服务如何独善其身

前面讲过,使用微服务时,很多时候需要跨多个服务去更新多个数据库的数据,架构如图13-1所示。

• 图13-1 微服务上下游示意图

如图13-1所示,如果业务正常运转,3个服务的数据应该分别变为a2、b2、c2,此时数据才一致。但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况,整个处理链条有可能在步骤2失败,这时数据就会变成a2、b1、c1;当然也有可能在步骤3失败,最终数据就会变成a2、b2、c1。这样数据就出错了,即数据不一致。

在本章所讨论的项目开始之前,因为之前的改造项目时间很紧,所以开发人员完全没有精力处理系统数据一致性的问题,最终业务系统出现了很多错误数据,业务部门发工单告知IT部门数据有问题,经过一番检查后,IT部门发现是因为分布式更新的原因导致了数据不一致。

此时,IT部门不得不抽出时间针对数据一致性问题给出一个可靠的解决方案。通过讨论,IT部门把数据一致性的问题归类为以下两种情况。

1.实时数据不一致可以接受,但要保证数据的最终一致性

因为一些服务出现错误,导致图13-1中的步骤3失败,此时处理完请求后,数据就变成了a2、b2、c1,不过没关系,只需保证最终数据是a2、b2、c2即可。

在以往的一个项目中,业务场景是这样的(示例有所简化):零售下单时,一般需要实现在商品服务中扣除商品的库存、在订单服务中生成一个订单、在交易服务中生成一个交易单这3个步骤。假设交易单生成失败,就会出现库存扣除、订单生成,但交易单没有生成的情况,此时只需保证最终交易单成功生成即可,这就是最终一致性。

2.必须保证实时一致性

如果图13-1中的步骤2和步骤3成功了,数据就会变成b2、c2,但是如果步骤3失败,那么步骤1和步骤2会立即回滚,保证数据变回a1、b1。

在以往的一个项目中,业务场景类似这样:用户使用积分兑换折扣券时,需要实现扣除用户积分、生成一张折扣券给用户这两个步骤。如果还是使用最终一致性方案的话,有可能出现用户积分扣除而折扣券还未生成的情况,此时用户进入账户发现积分没有了,也没有折扣券,就会马上投诉。

那怎么办呢?直接将前面的步骤回滚,并告知用户处理失败请继续重试即可,这就是实时一致性。

针对以上两种情况,具体解决方案是什么呢?下面一起来看看。

最终一致性方案

对于数据要求最终一致性的场景,实现思路是这样的。

1)每个步骤完成后,生产一条消息给MQ,告知下一步处理接下来的数据。

2)消费者收到这条消息,将数据处理完成后,与步骤1)一样触发下一步。

3)消费者收到这条消息后,如果数据处理失败,这条消息应该保留,直到消费者下次重试。

将3个服务的整个调用流程走下来,逻辑还是比较复杂的,整体流程如图13-2所示。

• 图13-2 服务调用流程

详细的实现逻辑如下。

1)调用端调用Service A。

2)Service A将数据库中的a1改为a2。

3)Service A生成一条步骤2(暂且命名为Step2)的消息给MQ。

4)Service A返回成功信息给调用端。

5)Service B监听Step2的消息,获得一条消息。

6)Service B将数据库中的b1改为b2。

7)Service B生成一条步骤3(暂且命名为Step3)的消息给MQ。

8)Service B将Step2的消息设置为已消费。

9)Service C监听Step3的消息,获得一条消息。

10)Service C将数据库中的c1改为c2。

11)Service C将Step3的消息设置为已消费。

接下来要考虑,如果每个步骤失败了该怎么办?

1)调用端调用Service A。

解决方案:直接返回失败信息给用户,用户数据不受影响。

2)Service A将数据库中的a1改为a2。

解决方案:如果这一步失败,就利用本地事务数据直接回滚,用户数据不受影响。

3)Service A生成一条步骤2)(Step2)的消息给MQ。

解决方案:如果这一步失败,就利用本地事务数据将步骤2)直接回滚,用户数据不受影响。

4)Service A返回成功信息给调用端。

解决方案:不用处理。

5)Service B监听Step2的消息,获得一条消息。

解决方案:如果这一步失败,MQ有对应机制,无须担心。

6)Service B将数据库中的b1改为b2。

解决方案:如果这一步失败,则利用本地事务直接将数据回滚,再利用消息重试的特性重新回到步骤5)。

7)Service B生成一条步骤3)(Step3)的消息给MQ。

解决方案:如果这一步失败,MQ有生产消息失败重试机制。若出现极端情况,服务器会直接崩溃,因为Step2的消息还没有消费,MQ会有重试机制,然后找另一个消费者重新从步骤5)执行。

8)Service B将Step2的消息设置为已消费。

解决方案:如果这一步失败,MQ会有重试机制,找另一个消费者重新从步骤5)执行。

9)Service C监听Step3的消息,获得一条消息。

解决方案:参考步骤5)的解决方案。

10)Service C将数据库中的c1改为c2。

解决方案:参考步骤6)的解决方案。

11)Service C将Step3的消息设置为已消费。

解决方案:参考步骤8)的解决方案。

以上就是最终一致性的解决方案,这个方案还有两个问题。

1)因为利用了MQ的重试机制,所以有可能出现步骤6)和步骤10)重复执行的情况,此时该怎么办?比如,上面流程中的步骤8)如果失败了,就会从步骤5)重新执行,这时就会出现步骤6)执行两遍的情况。为此,在下游(步骤6)和步骤10))更新数据时,需要保证业务代码的幂等性(关于幂等性,在第1章提过)。

2)如果每个业务流程都需要这样处理,岂不是需要额外写很多代码?那是否可以将类似流程的重复代码抽取出来?答案是可以,这里使用的MQ相关逻辑在其他业务流程中也通用,这个项目最终就是将这些代码抽取出来并进行了封装。因为重复代码抽取的方法比较简单,这里就不展开了。

实时一致性方案

实时一致性其实就是常说的分布式事务。

MySQL其实有一个两阶段提交的分布式事务方案MySQL XA,但是该方案存在严重的性能问题。比如,一个数据库的事务与多个数据库间的XA事务性能可能相差10倍。另外,XA的事务处理过程会长期占用锁资源,所以项目组一开始就没有考虑这个方案。

而当时比较流行的方案是使用TCC模式,下面简单介绍一下。

TCC模式

在TCC模式中,会把原来的一个接口分为Try接口、Confirm接口、Cancel接口。

1)Try接口:用来检查数据、预留业务资源。

2)Confirm接口:用来确认实际业务操作、更新业务资源。

3)Cancel接口:是指释放Try接口中预留的资源。

比如在积分兑换折扣券的例子中,需要调用账户服务减积分(步骤1)、营销服务加折扣券(步骤2)这两个服务,那么针对账户服务减积分这个接口,需要写3个方法,代码如下所示。


 

同样,针对营销服务加折扣券这个接口,也需要写3个方法,而后调用的大体步骤如图13-3所示。

• 图13-3 账户和营销服务TCC处理流程

图13-3中,除Cancel步骤以外的步骤,代表成功的调用路径,如果中间出错,则去调用相关服务的回退(Rollback)方法进行手工回退。该方案原来只需要在每个服务中写一段业务代码,而现在需要分成3段来写,而且还涉及一些注意事项。

1)需要保证每个服务的Try方法执行成功后,Confirm方法在业务逻辑上能够执行成功。

2)可能会出现Try方法执行失败而Cancel被触发的情况,此时需要保证正确回滚。

3)可能因为网络拥堵而出现Try方法调用被堵塞的情况,此时事务控制器判断Try失败并触发了Cancel方法,之后Try方法的调用请求到了服务这里,应该拒绝Try请求逻辑。

4)所有的Try、Confirm、Cancel都需要确保幂等性。

5)整个事务期间的数据库数据处于一个临时的状态,其他请求需要访问这些数据时,需要考虑如何正确被其他请求使用,而这种使用包括读取和并发的修改。

所以,TCC模式是一个实施起来很麻烦的方案,除了每个业务代码的工作量乘3之外,还需要通过相应逻辑应对上面的注意事项,这样出错的概率就太高了。

后来,笔者在一篇介绍Seata的文章中了解到AT模式也能解决这个问题。

Seata中AT模式的自动回滚

自动回滚对于使用Seata的人来说操作比较简单,只需要在触发整个事务的业务发起方的方法中加入@GlobalTransactional标注,并且使用普通的@Transactional包装好分布式事务中相关服务的相关方法即可。

对于Seata的内在机制,AT模式的自动回滚往往需要执行以下步骤(分为3个阶段)。

阶段1

1)解析每个服务方法执行的SQL,记录SQL的类型(Update、Insert或Delete),修改表并更新SQL条件等信息。

2)根据前面的条件信息生成查询语句,并记录修改前的数据镜像。

3)执行业务的SQL。4)记录修改后的数据镜像。

5)插入回滚日志:把前后镜像数据及业务SQL相关的信息组成一条回滚日志记录,插入UNDOLOG表中。

6)提交前,向TC注册分支,并申请相关修改数据行的全局锁。

7)本地事务提交:业务数据的更新与前面步骤生成的UNDOLOG一并提交。

8)将本地事务提交的结果上报给事务控制器。

阶段2

收到事务控制器的分支回滚请求后,开启一个本地事务,执行如下操作。

1)查找相应的UNDOLOG记录。

2)数据校验:将UNDOLOG中的后镜像数据与当前数据进行对比,如果存在不同,说明数据被当前全局事务之外的动作做了修改,此时需要根据配置策略进行处理。

3)根据UNDOLOG中的前镜像数据和业务SQL的相关信息生成回滚语句并执行。

4)提交本地事务,并把本地事务的执行结果(即分支事务回滚的结果)上报事务控制器。

阶段3

1)收到事务控制器的分支提交请求后,将请求放入一个异步任务队列

中,并马上返回提交成功的结果给事务控制器。

2)异步任务阶段的分支提交请求将异步、批量地删除相应的UNDOLOG记录。

以上就是Seata AT模式的简单介绍。

尝试Seata

当时,虽然Seata还没有更新到1.0,且官方也不推荐线上使用,但是项目组最终还是使用了它,原因如下。

1)因为实时一致性的场景很少,而且发生频率低,所以并不会大规模使用,影响面在可控范围内。如果实时一致性的场景发生频率高,并发量就高,业务人员对性能的要求也高,此时就会与业务沟通,采用最终一致性的方案。

2)Seata AT模式与TCC模式相比,只有增加一个@GlobalTransactional的工作量,因此两者的工作量相差很多,也就是说,对项目组来说,投入产出比更高,值得冒险。这可能也是Seata发展很快的原因之一。

虽然Seata AT模式有些小缺陷,但是瑕不掩瑜。

小结

最终一致性与实时一致性的解决方案设计完成后,不仅没有给业务开发人员带来额外工作量,也没有影响业务项目进度的日常推进,还大大减少了数据不一致的出现概率,因此数据不一致的痛点得到了较大缓解。



Tags:微服务   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
对于微服务架构监控应该遵守的原则
随着软件交付方式的变革,微服务架构的兴起使得软件开发变得更加快速和灵活。在这种情况下,监控系统成为了微服务控制系统的核心组成部分。随着软件的复杂性不断增加,了解系统的...【详细内容】
2024-04-03  Search: 微服务  点击:(5)  评论:(0)  加入收藏
PHP+Go 开发仿简书,实战高并发高可用微服务架构
来百度APP畅享高清图片//下栽のke:chaoxingit.com/2105/PHP和Go语言结合,可以开发出高效且稳定的仿简书应用。在实现高并发和高可用微服务架构时,我们可以采用一些关键技术。首...【详细内容】
2024-01-14  Search: 微服务  点击:(115)  评论:(0)  加入收藏
九条微服务最佳实践,你学会了哪条?
微服务之间连贯一致的代码库对于可维护性至关重要。保持代码成熟度相似,可确保系统统一演进,防止服务间出现性能、安全性和功能差异。在开发微服务时,我们需要遵循哪些最佳实践...【详细内容】
2024-01-05  Search: 微服务  点击:(99)  评论:(0)  加入收藏
Go微服务入门到容器化实践
Go微服务入门到容器化实践Go 是一门高效、现代化、快速增长的编程语言,非常适合构建 Web 应用程序。而 Docker 是一种轻量级的容器化技术,能够使得您的应用程序在任何地方运行...【详细内容】
2024-01-01  Search: 微服务  点击:(64)  评论:(0)  加入收藏
微服务全做错了!谷歌提出新方法,成本直接降为1/9!
2023,微服务“水逆”之年。长期以来,不管大厂还是小厂,微服务都被认为是云原生服务应用程序架构的事实标准,然而2023,不止那位37signals的DHH决心下云,放弃微服务,就连亚马逊和谷歌...【详细内容】
2023-12-29  Search: 微服务  点击:(121)  评论:(0)  加入收藏
微服务架构中的数据一致性
在微服务中,一个逻辑上原子操作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案,如果其中一个分布式流程参...【详细内容】
2023-12-27  Search: 微服务  点击:(144)  评论:(0)  加入收藏
监控 Spring Cloud 微服务的实践方案
一、简介Spring Cloud是一个基于Spring Boot实现的微服务框架,它提供了丰富的微服务功能,如分布式配置、服务注册与发现、服务熔断、负载均衡等。为了更好地管理和监控这样复...【详细内容】
2023-12-19  Search: 微服务  点击:(145)  评论:(0)  加入收藏
聊聊微服务链路服务
微服务架构图片如果有用户反馈某个页面很慢,我们知道这个页面的请求调用链是 A -----> C -----> B -----> D(图片有误),怎么来定位是由哪个服务引起的问题呢? 更进一步,如果...【详细内容】
2023-12-15  Search: 微服务  点击:(127)  评论:(0)  加入收藏
选择适合微服务的编程语言,让你的工作事半功倍!
讨论编程语言就像是一场政治辩论。每个开发者都会过分捍卫他/她所使用的编程语言。然而,编程语言应该被看作是它们真正是的东西,即一种工作工具。每种编程语言都有特定的目的...【详细内容】
2023-12-14  Search: 微服务  点击:(178)  评论:(0)  加入收藏
Eureka: 微服务架构中不可或缺的服务治理工具
Eureka是Netflix开源的一款用于服务治理的工具,它是NetflixOSS(OpenSourceSoftware)项目的一部分,主要用于实现微服务架构中的服务注册与发现。在当今庞大而复杂的微服务系统中,E...【详细内容】
2023-12-14  Search: 微服务  点击:(194)  评论:(0)  加入收藏
▌简易百科推荐
对于微服务架构监控应该遵守的原则
随着软件交付方式的变革,微服务架构的兴起使得软件开发变得更加快速和灵活。在这种情况下,监控系统成为了微服务控制系统的核心组成部分。随着软件的复杂性不断增加,了解系统的...【详细内容】
2024-04-03  步步运维步步坑    Tags:架构   点击:(5)  评论:(0)  加入收藏
大模型应用的 10 种架构模式
作者 | 曹洪伟在塑造新领域的过程中,我们往往依赖于一些经过实践验证的策略、方法和模式。这种观念对于软件工程领域的专业人士来说,已经司空见惯,设计模式已成为程序员们的重...【详细内容】
2024-03-27    InfoQ  Tags:架构模式   点击:(13)  评论:(0)  加入收藏
哈啰云原生架构落地实践
一、弹性伸缩技术实践1.全网容器化后一线研发的使用问题全网容器化后一线研发会面临一系列使用问题,包括时机、容量、效率和成本问题,弹性伸缩是云原生容器化后的必然技术选择...【详细内容】
2024-03-27  哈啰技术  微信公众号  Tags:架构   点击:(10)  评论:(0)  加入收藏
DDD 与 CQRS 才是黄金组合
在日常工作中,你是否也遇到过下面几种情况: 使用一个已有接口进行业务开发,上线后出现严重的性能问题,被老板当众质疑:“你为什么不使用缓存接口,这个接口全部走数据库,这怎么能扛...【详细内容】
2024-03-27  dbaplus社群    Tags:DDD   点击:(12)  评论:(0)  加入收藏
高并发架构设计(三大利器:缓存、限流和降级)
软件系统有三个追求:高性能、高并发、高可用,俗称三高。本篇讨论高并发,从高并发是什么到高并发应对的策略、缓存、限流、降级等。引言1.高并发背景互联网行业迅速发展,用户量剧...【详细内容】
2024-03-13    阿里云开发者  Tags:高并发   点击:(6)  评论:(0)  加入收藏
如何判断架构设计的优劣?
架构设计的基本准则是非常重要的,它们指导着我们如何构建可靠、可维护、可测试的系统。下面是这些准则的转换表达方式:简单即美(KISS):KISS原则的核心思想是保持简单。在设计系统...【详细内容】
2024-02-20  二进制跳动  微信公众号  Tags:架构设计   点击:(36)  评论:(0)  加入收藏
详解基于SpringBoot的WebSocket应用开发
在现代Web应用中,实时交互和数据推送的需求日益增长。WebSocket协议作为一种全双工通信协议,允许服务端与客户端之间建立持久性的连接,实现实时、双向的数据传输,极大地提升了用...【详细内容】
2024-01-30  ijunfu  今日头条  Tags:SpringBoot   点击:(19)  评论:(0)  加入收藏
PHP+Go 开发仿简书,实战高并发高可用微服务架构
来百度APP畅享高清图片//下栽のke:chaoxingit.com/2105/PHP和Go语言结合,可以开发出高效且稳定的仿简书应用。在实现高并发和高可用微服务架构时,我们可以采用一些关键技术。首...【详细内容】
2024-01-14  547蓝色星球    Tags:架构   点击:(115)  评论:(0)  加入收藏
GraalVM与Spring Boot 3.0:加速应用性能的完美融合
在2023年,SpringBoot3.0的发布标志着Spring框架对GraalVM的全面支持,这一支持是对Spring技术栈的重要补充。GraalVM是一个高性能的多语言虚拟机,它提供了Ahead-of-Time(AOT)编...【详细内容】
2024-01-11    王建立  Tags:Spring Boot   点击:(124)  评论:(0)  加入收藏
Spring Boot虚拟线程的性能还不如Webflux?
早上看到一篇关于Spring Boot虚拟线程和Webflux性能对比的文章,觉得还不错。内容较长,抓重点给大家介绍一下这篇文章的核心内容,方便大家快速阅读。测试场景作者采用了一个尽可...【详细内容】
2024-01-10  互联网架构小马哥    Tags:Spring Boot   点击:(118)  评论:(0)  加入收藏
站内最新
站内热门
站内头条