企业网站建设平台,义乌门户网站建设,电子商务网站开发公司,有域名和服务器怎么建网站四月初#xff0c;去面试了本市的一家之前在做办公室无人货架的公司#xff0c;虽然他们现在在面临着转型#xff0c;但是对于我这种想从传统企业往互联网行业走的孩子来说#xff0c;还是比较有吸引力的。在面试过程中就提到了分布式事物问题。我又一次在没有好好整理的问… 四月初去面试了本市的一家之前在做办公室无人货架的公司虽然他们现在在面临着转型但是对于我这种想从传统企业往互联网行业走的孩子来说还是比较有吸引力的。在面试过程中就提到了分布式事物问题。我又一次在没有好好整理的问题上吃了亏记录一下还是长记性 先看面试过程面试官先是在纸上先画了这样一张图让我看这张图按照上面的流程走有没有什么问题面试官并没有直接说出来这里面会有分布式事物的问题而是让我来告诉他这就是面试套路呀。我回答了这中间可能存在分布式事物的问题当步骤2在调用 B 系统时可能存在B 系统处理完成后在响应的时候超时导致 A 系统误认为 B 处理失败了从而导致A 系统回滚跟 B 系统存在数据不一致的情况。ok 我回答到这里应该回答了面试官的第一层意思至少我有这种意识他点了点头。接着他继续问“那你有什么好的解决方式吗”此时我脑子里面只有两阶段提交的大概流程图的印象然后巴卡巴拉的跟他说了一番什么中间来个协调者呀先预提交什么的如果有失败就 rollback如果 ok再真正的提交事物就是网上这些大神们说的这些理论。然后面试官就继续问那A 在调用 B 的这条线断了你们代码具体是怎么处理的呢 怎么来做到 rollback 的呢 说说你代码怎么写的。此时我懵了。最后结果大家肯定也能猜到凉凉。什么是事务这里我们说的事务一般是指 数据库事务简称 事务是数据库管理系统执行过程中的一个逻辑单位由一个有限的数据库操作序列构成。维基百科中这么说的。用转账的例子来说A 账户要给 B 账户转 100块这中间至少包含了两个操作1.A 账户 减 100 块2.B 账户 加 100 块在支持事务的数据库管理系统来说就是得确保上面两个操作整个“事务”都能完成不能存在A 的100块扣了然后B的账户又没加上去的情况。数据库事务包含了四个特性分别是•原子性Atomicity事务作为一个整体被执行包含在其中的对数据库的操作要么全部被执行要么都不执行。对于转账来说A账户扣钱B 账户加钱要么同时成功要么同时失败。•一致性Consistency事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束•隔离性Isolation多个事务并发执行时一个事务的执行不应影响其他事务的执行。其他账户在转账的时候不能影响到上面的 A 跟 B 之前的交易。•持久性Durability已被提交的事务对数据库的修改应该永久保存在数据库中。什么是分布式事物我们知道上面的转账 我们是在一个数据库中的事务操作。我们可以使用一些框架 比如 Spring 的事务管理器来给我们统一搞定。但是如果我们系统中出现垮库操作比如一个操作中我需要操作多个库或者说这个操作会垮应用之前的调用那么Spring 的事务管理机制就对这种场景没有办法了。就像上面面试题中出现的问题一样在系统 A 的步骤 2 在远程调用 B 的时候由于网络超时导致B 没有正常响应但是A 这边调用失败进行了回滚而 B 又提交了事物。此时就可能会导致数据不一致的情况参生分布式事物的问题。分布式事物的存在就是解决数据不一致的情况。为什么我们要保证一致性CAP 理论分布式系统中有这么一个广为流传的理论CAP 定理这个定理呀起源于加州大学柏克莱分校University of California, Berkeley的计算机科学家埃里克·布鲁尔在 2000年的分布式计算原理研讨会PODC上提出的一个猜想。后来在2002年麻省理工学院MIT的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明使之成为一个定理。【摘自维基百科】他说呀对于一个分布式计算系统来说不可能同时满足以下三点•一致性Consistency•可用性Availability•分区容错性Partition tolerance而一个分布式系统最多只能满足其中的两项。那么上面的三点分别是什么玩意儿为什么又只能同时满足两项呢我们先看这样一个场景现在我们系统部署了两份两个节点web1 和 web2 ,同样的业务代码但是维护的是自己这个节点生成的数据。但是用户访问进来可能会访问到不同的节点。但是不管是访问web1 还是web2 ,在用户参数数据 过后这个数据都必须得同步到另外的节点让用户不管访问哪个节点都是响应他需要的数据。如下图分区容错性我们先说 分区容错性也就是说呀就算上面这两个节点之间发生了网络故障无法发生同步的问题但是用户访问进来不管到哪个节点这个节点都得单独提供服务这一点对于互联网公司来说是必须要满足的。当 web1 和 web2 之间的网络发生故障导致数据无法进行同步。用户在web1 上写了数据马上又访问进来读取数据请求到了 web2但是此时 web2 是没有数据的。那么我们是 给用户返回 null 还是说给一些提示说系统不可用稍后重试呢都不妥吧兄弟。一致性如果要保证可用性那么有数据的节点返回数据没数据的节点返回 null ,就会出现用户那里看到的是一会儿有数据一会儿没有数据此时就存在 一致性 的问题。可用性如果保证一致性那么在用户访问的时候不管 web1 还是web2 我们可能会返回一些提示信息说系统不可用稍后再试等等保证每次都是一致的。明明我们有数据在但是我们系统却响应的是提示信息此时就是 可用性 的问题。由于分区容错性P是必须保证的那么我们分布式系统就更多是在一致性CP 和可用性AP上做平衡了只能同时满足两个条件。其实大家想想ZK 是不是就是严格实现了 CP 而 Eureka 则是保证了 AP。其实分布式事物强调的就是一致性。几种分布式事物解决方案2PC在说 2PC 之前我们先了解一下 XA规范 是个什么东西XA规范 描述了全局的事务管理器与局部的资源管理器之间的接口。XA规范的目的是允许多个资源如数据库应用服务器消息队列等等在同一事务中访问这样可以使ACID属性跨越应用程序而保持有效。XA 使用 两阶段提交2PC 来保证所有资源同时提交或回滚任何特定的事务。大家想一个场景在做单应用的时候有的同学连过两个库吧在一个事物中会同时向两个系统插入数据。但是对于普通事物来讲是管不了的。看下图只是举例这种操作的套路不局限于下面的业务一个服务里面要去操作两个库如何保证事物成功呢。这里我们介绍一个框架 Atomikos 他就是实现了这种 XA 的套路。看代码具体代码移步 Github AtomikosJTATest[1]: https://github.com/heyxyw/learn/blob/master/distributed-transaction/src/main/java/com/zhouq/jta/AtomikosJTATest.java[2]看到上面的图了哇Atomikos 自己实现了一个事物管理器。我们获取的连接都从它哪里拿。•第一步先开启事务然后进行预提交db1 和 db2 都先进行预先执行注意这里没有提交事物。•第二步才是真正的提交事物由 Atomikos 来发起提交的如果出现异常则发起回滚操作。这个过程是不是就有两个角色了一个 事务管理器一个资源管理器我们这里是 数据库也可以是其他的组件消息队列什么的。整个执行过程是这样上图是正常情况下图是一方出现故障的情况。图片来自XA 事务处理[3]https://www.infoq.cn/article/xa-transactions-handle[4] 具体关于XA 的详细讲解可以好好看看。整个2PC 的流程第一阶段提交请求阶段协调者节点向所有参与者节点询问是否可以执行提交操作并开始等待各参与者节点的响应。参与者节点执行询问发起为止的所有事务操作并将Undo信息和Redo信息写入日志。各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功则它返回一个同意消息如果参与者节点的事务操作实际执行失败则它返回一个中止消息。第二阶段 (提交执行阶段)成功当协调者节点从所有参与者节点获得的相应消息都为同意时1.协调者节点向所有参与者节点发出正式提交的请求。2.参与者节点正式完成操作并释放在整个事务期间内占用的资源。3.参与者节点向协调者节点发送完成消息。4.协调者节点收到所有参与者节点反馈的完成消息后完成事务。失败如果任一参与者节点在第一阶段返回的响应消息为终止或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时1.协调者节点向所有参与者节点发出回滚操作的请求。2.参与者节点利用之前写入的Undo信息执行回滚并释放在整个事务期间内占用的资源。3.参与者节点向协调者节点发送回滚完成消息。4.协调者节点收到所有参与者节点反馈的回滚完成消息后取消事务。有时候第二阶段也被称作完成阶段因为无论结果怎样协调者都必须在此阶段结束当前事务。可靠消息最终一致性方案基于普通的消息队列中间件上面我们说了两阶段提交的方案接下来我们讲讲怎么基于可靠消息最终一致性方案来解决分布式事物的问题。这个方案就有消息服务中间件角色参与进来了。我们先看一个大提的流程图我们以创建订单下单过程和 后面出库 的流程为例来讲述上面的图。在下单逻辑里面Producer 端我们先生成一个订单的数据比如订单号数量等关键的信息先包装成一条消息并把消息的状态置为 init ,然后发送到 独立消息服务中并且入库。接下来继续处理 下单的其他本地的逻辑。处理完成后走到确认发送消息这一步说明我的订单是能够下成功的。那么我们再向消息服务里面发送一条confirm 的消息消息服务里面就可以把这个订单的消息状态修改为 send 并且发送到消息队列里面。接下来消费者端去消费这条消息。处理自己这边的逻辑处理完成以后然后反馈消息处理结果到独立消息服务独立消息服务把消息状态置为 end 状态 ,表示结束。但是得注意保证接口的幂等性避免重复消费带来的问题。这里面可能出现的问题以及各个步骤怎么解决的1.比如在 prepare 阶段就发生异常那么这里订单这块都不会下成功。但是我们说我们这里是基于可靠消息得保证我们的消息服务是正常的。2.在 comfirm 出现异常此时发送确认失败但是我们的单已经下成功了。这种情况我们就可以在独立消息服务中起一个定时任务定时去查询 消息状态为 init 的数据去反向查询 订单系统中的单号是否存在如果存在那么我们就把消息置为 send 状态然后发送到 消息队列里面如果查询到不存在的订单那么就直接抛弃掉这条消息。所以这里我们的订单系统得提供批量查询订单的接口还有下游的消费系统得保证幂等。保证重复消费的一致性。3.消息队列丢消息或者下游系统一直处理失败导致没有消息反馈过来出现一直是 send 状态的消息。此时独立消息我们还需要一个定时任务就是处理这种 send 状态的消息我们可以进行重发直到后面系统消费成功为止。4.最后消费者这端我们在消费的时候如果出现消费异常或者是系统bug 导致异常的情况。那么这里我们还可以去记录日志如果不是系统代码问题是网络抖动导致的那么在上面第三种情况消息系统会重新发送消息我们再处理就是。如果是一直失败你就要考虑是不是你的代码真的有问题有bug 了吧。5.最后的保底方案记录日志出现问题人肉处理数据。现在我们系统出现错误以目前的技术手段是没办法做到都靠机器去解决的都得靠我们人。据我了解现在很多大厂都会有这样的人专门处理这种类型的问题手动去修改数据库的方式。我们之前待的小厂基本上都是靠我们自己去写 sql 去修改数据的想想是不是贴一下关键的独立消息服务核心逻辑代码框架定时任务基于 RocketMQ实现这种方案跟上面的独立消息服务一致这里直接去掉独立服务只利用消息队列来实现也就是阿里的 RocketMQ 。流程图如下这里的整个流程跟上面基于消息服务是一致的。这里就不过多阐述具体代码实现请参考 https://www.jianshu.com/p/453c6e7ff81c[5] 写得非常好。针对这里的 可靠消息最终一致性方案 来说我们说的 可靠 是指保证消息一定能发送到消息中间件里面去保证这里可靠。对于下游的系统来说消费不成功一般来说就是采取失败重试重试多次不成功那么就记录日志后续人工介入来进行处理。所以这里得强调一下后面的系统一定要处理 幂等重试日志 这几个东西。如果是对于资金类的业务后续系统回滚了以后得想办法去通知前面的系统也进行回滚或者是发送报警由人工来手工回滚和补偿。TCC 方案TCC 的全程分为三个阶段分别是 Try、Confirm、Cancel1.Try阶段这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留2.Confirm阶段这个阶段说的是在各个服务中执行实际的操作3.Cancel阶段如果任何一个服务的业务方法执行出错那么这里就需要进行补偿就是执行已经执行成功的业务逻辑的回滚操作还是以转账的例子为例在跨银行进行转账的时候需要涉及到两个银行的分布式事物从A 银行向 B 银行转 1 块如果用TCC 方案来实现大概思路就是这样的1.Try 阶段先把A 银行账户先冻结 1 块B银行账户中的资金给预加 1 块。2.Confirm 阶段执行实际的转账操作A银行账户的资金扣减 1块B 银行账户的资金增加 1 块。3.Cancel 阶段如果任何一个银行的操作执行失败那么就需要回滚进行补偿就是比如A银行账户如果已经扣减了但是B银行账户资金增加失败了那么就得把A银行账户资金给加回去。这种方案就比较复杂了一步操作要做多个接口来配合完成。以 ByteTCC 框架的实现例子来大概描述一下上面的流程示例地址 https://gitee.com/bytesoft/ByteTCC-sample/tree/master/dubbo-sample[6]最开始 A 银行账户 与 B 银行账户都分别为amount数量1000frozen冻结金额 0从A银行账户发起转账到 B 银行账户 1 块try 阶段A 银行账户金额减 1冻结金额 加 1B 银行 账户 冻结金额加 1 。此时•A 银行账户amount数量 1000 - 1 999frozen冻结金额 0 1 1•B 银行账户amount数量 1000frozen冻结金额 0 1 1confirm 阶段 A银行账户冻结金额 减 1B 银行账户金额 加 1冻结金额 减 1此时•A 银行账户amount数量 999frozen冻结金额 1 - 1 0•B 银行账户amount数量 1000 1 1001frozen冻结金额 1 - 1 0cancel 阶段A 银行账户金额 1冻结金额 -1 B 银行 冻结金额 -1此时•A 银行账户amount数量 999 1 1000frozen冻结金额 1 - 1 0•B 银行账户amount数量 1000frozen冻结金额 1 - 1 0至此整个过程就演示完毕大家记得跑一遍代码。其实还是蛮复杂的有许多接口一起来配合完成整个业务试想一下如果我们项目中大量用到 TCC 来写你受得了再提一下 BASE理论BASE 理论是 Basically Available(基本可用)Soft State软状态和Eventually Consistent最终一致性三个短语的缩写。1.基本可用Basically Available指分布式系统在出现不可预知故障的时候允许损失部分可用性。2.软状态 Soft State指允许系统中的数据存在中间状态并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。3.最终一致 Eventual Consistency强调的是所有的数据更新操作在经过一段时间的同步之后最终都能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致而不需要实时保证系统数据的强一致性。其核心思想是即使无法做到强一致性Strong consistency但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性Eventual consistency到这里大家再想想 上面 TCC 方案中的账户设计了一个冻结字段 frozen 这里是不是就是 BASE理论 中间的 软状态 呢 最后对存在非常多的微服务的公司来说服务之间的调用异常的复杂那么在引入分布式事物的过程中你需要考虑加入分布式事物后系统实现起来的复杂性和开发成本或者说哪些地方根本就不需要搞分布式事物。其实没必要到处都搞分布式事物对于大多数的业务来说其实我们并不需要做分布式事物直接做日志做监控就好了。然后出现问题手工去处理一个月也不会有那么多的问题的。如果你天天都出现这些问题你是不是要好好去排查排查你的代码Bug了。对于资金类的场景那么基本上会采用分布式事物方案来保证像其他的服务会员积分商品信息呀这些可能就不需要这么去搞了。作者介绍乔二爷在成都乔二爷这个名字是之前身边的同事给取的也不知道为啥。也习惯了他们这样叫我。一直待在相对传统一点的企业有四年半的 Java 开发经验会点大数据的内容也跟客户打过一年的交道还带过 10个月 10人的技术团队有一定的协调组织能力能够理解 boss 的工作内容也能很好的配合别人做事。【End】重磅消息为了回馈读者朋友老王准备了500元的微信红包点击参与领取关注下方二维码订阅更多精彩内容。转发朋友圈是对我最大的支持。
