建设网站技术标准,腾讯qq,哪个应用市场软件最全,wordpress模板前言 最近很久没有写博客了#xff0c;一方面是因为公司事情最近比较忙#xff0c;另外一方面是因为在进行 CAP 的下一阶段的开发工作#xff0c;不过目前已经告一段落了。 接下来还是开始我们今天的话题#xff0c;说说分布式事务#xff0c;或者说是我眼中的分布式事务一方面是因为公司事情最近比较忙另外一方面是因为在进行 CAP 的下一阶段的开发工作不过目前已经告一段落了。 接下来还是开始我们今天的话题说说分布式事务或者说是我眼中的分布式事务因为每个人可能对其的理解都不一样。 分布式事务是企业集成中的一个技术难点也是每一个分布式系统架构中都会涉及到的一个东西特别是在微服务架构中几乎可以说是无法避免本文就分布式事务来简单聊一下。 数据库事务 在说分布式事务之前我们先从数据库事务说起。 数据库事务可能大家都很熟悉在开发过程中也会经常使用到。但是即使如此可能对于一些细节问题很多人仍然不清楚。比如很多人都知道数据库事务的几个特性原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)简称就是ACID。但是再往下比如问到隔离性指的是什么的时候可能就不知道了或者是知道隔离性是什么但是再问到数据库实现隔离的都有哪些级别或者是每个级别他们有什么区别的时候可能就不知道了。 本文并不打算介绍这些数据库事务的这些东西有兴趣可以搜索一下相关资料。不过有一个知识点我们需要了解就是假如数据库在提交事务的时候突然断电那么它是怎么样恢复的呢 为什么要提到这个知识点呢 因为分布式系统的核心就是处理各种异常情况这也是分布式系统复杂的地方因为分布式的网络环境很复杂这种“断电”故障要比单机多很多所以我们在做分布式系统的时候最先考虑的就是这种情况。这些异常可能有 机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失、其他异常等等... 我们接着说本地事务数据库断电的这种情况它是怎么保证数据一致性的呢我们使用SQL Server来举例我们知道我们在使用 SQL Server 数据库是由两个文件组成的一个数据库文件和一个日志文件通常情况下日志文件都要比数据库文件大很多。数据库进行任何写入操作的时候都是要先写日志的同样的道理我们在执行事务的时候数据库首先会记录下这个事务的redo操作日志然后才开始真正操作数据库在操作之前首先会把日志文件写入磁盘那么当突然断电的时候即使操作没有完成在重新启动数据库时候数据库会根据当前数据的情况进行undo回滚或者是redo前滚这样就保证了数据的强一致性。 接着我们就说一下分布式事务。 分布式理论 当我们的单个数据库的性能产生瓶颈的时候我们可能会对数据库进行分区这里所说的分区指的是物理分区分区之后可能不同的库就处于不同的服务器上了这个时候单个数据库的ACID已经不能适应这种情况了而在这种ACID的集群环境下再想保证集群的ACID几乎是很难达到或者即使能达到那么效率和性能会大幅下降最为关键的是再很难扩展新的分区了这个时候如果再追求集群的ACID会导致我们的系统变得很差这时我们就需要引入一个新的理论原则来适应这种集群的情况就是 CAP 原则或者叫CAP定理那么CAP定理指的是什么呢 CAP定理 CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的他指出WEB服务无法同时满足一下3个属性 一致性(Consistency) 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分布式系统中在任何数据库设计中一个Web应用至多只能同时支持上面的两个属性。显然任何横向扩展策略都要依赖于数据分区。因此设计人员必须在一致性与可用性之间做出选择。 这个定理在迄今为止的分布式系统中都是适用的 为什么这么说呢 这个时候有同学可能会把数据库的2PC两阶段提交搬出来说话了。OK我们就来看一下数据库的两阶段提交。 对数据库分布式事务有了解的同学一定知道数据库支持的2PC又叫做 XA Transactions。 MySQL从5.5版本开始支持SQL Server 2005 开始支持Oracle 7 开始支持。 其中XA 是一个两阶段提交协议该协议分为以下两个阶段 第一阶段事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作并反映是否可以提交. 第二阶段事务协调器要求每个数据库提交数据。 其中如果有任何一个数据库否决此次提交那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。 如果CAP 定理是对的那么它一定会影响到可用性。 如果说系统的可用性代表的是执行某项操作相关所有组件的可用性的和。那么在两阶段提交的过程中可用性就代表了涉及到的每一个数据库中可用性的和。我们假设两阶段提交的过程中每一个数据库都具有99.9%的可用性那么如果两阶段提交涉及到两个数据库这个结果就是99.8%。根据系统可用性计算公式假设每个月43200分钟99.9%的可用性就是43157分钟, 99.8%的可用性就是43114分钟相当于每个月的宕机时间增加了43分钟。 以上可以验证出来CAP定理从理论上来讲是正确的CAP我们先看到这里等会再接着说。 BASE理论 在分布式系统中我们往往追求的是可用性它的重要程序比一致性要高那么如何实现高可用性呢 前人已经给我们提出来了另外一个理论就是BASE理论它是用来对CAP定理进行进一步扩充的。BASE理论指的是 Basically Available基本可用 Soft state软状态 Eventually consistent最终一致性 BASE理论是对CAP中的一致性和可用性进行一个权衡的结果理论的核心思想就是我们无法做到强一致但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性Eventual consistency。 有了以上理论之后我们来看一下分布式事务的问题。 分布式事务 在分布式系统中要实现分布式事务无外乎那几种解决方案。 一、两阶段提交2PC 和上一节中提到的数据库XA事务一样两阶段提交就是使用XA协议的原理我们可以从下面这个图的流程来很容易的看出中间的一些比如commit和abort的细节。 两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。在实现方面在 .NET 中可以借助 TransactionScop 提供的 API 来编程实现分布式系统中的两阶段提交比如WCF中就有实现这部分功能。不过在多服务器之间需要依赖于DTC来完成事务一致性Windows下微软搞的有MSDTC服务Linux下就比较悲剧了。 另外说一句TransactionScop 默认不能用于异步方法之间事务一致因为事务上下文是存储于当前线程中的所以如果是在异步方法需要显式的传递事务上下文。 优点 尽量保证了数据的强一致适合对数据强一致要求很高的关键领域。其实也不能100%保证强一致 缺点 实现复杂牺牲了可用性对性能影响较大不适合高并发高性能场景如果分布式系统跨接口调用目前 .NET 界还没有实现方案。 二、补偿事务TCC TCC 其实就是采用的补偿机制其核心思想是针对每个操作都要注册一个与其对应的确认和补偿撤销操作。它分为三个阶段 Try 阶段主要是对业务系统做检测及资源预留 Confirm 阶段主要是对业务系统做确认提交Try阶段执行成功并开始执行 Confirm阶段时默认 Confirm阶段是不会出错的。即只要Try成功Confirm一定成功。 Cancel 阶段主要是在业务执行错误需要回滚的状态下执行的业务取消预留资源释放。 举个例子假入 Bob 要向 Smith 转账思路大概是 我们有一个本地方法里面依次调用 1、首先在 Try 阶段要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。 2、在 Confirm 阶段执行远程调用的转账的操作转账成功进行解冻。 3、如果第2步执行成功那么转账成功如果第二步执行失败则调用远程冻结接口对应的解冻方法 (Cancel)。 优点 跟2PC比起来实现以及流程相对简单了一些但数据的一致性比2PC也要差一些 缺点 缺点还是比较明显的在2,3步中都有可能失败。TCC属于应用层的一种补偿方式所以需要程序员在实现的时候多写很多补偿的代码在一些场景中一些业务流程可能用TCC不太好定义及处理。 三、本地消息表异步确保 本地消息表这种实现方式应该是业界使用最多的其核心思想是将分布式事务拆分成本地事务进行处理这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节 基本思路就是 消息生产方需要额外建一个消息表并记录消息发送状态。消息表和业务数据要在一个事务里提交也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败会进行重试发送。 消息消费方需要处理这个消息并完成自己的业务逻辑。此时如果本地事务处理成功表明已经处理成功了如果处理失败那么就会重试执行。如果是业务上面的失败可以给生产方发送一个业务补偿消息通知生产方进行回滚等操作。 生产方和消费方定时扫描本地消息表把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑这种方案还是非常实用的。 这种方案遵循BASE理论采用的是最终一致性笔者认为是这几种方案里面比较适合实际业务场景的即不会出现像2PC那样复杂的实现(当调用链很长的时候2PC的可用性是非常低的)也不会像TCC那样可能出现确认或者回滚不了的情况。 优点 一种非常经典的实现避免了分布式事务实现了最终一致性。在 .NET中 有现成的解决方案。 缺点 消息表会耦合到业务系统中如果没有封装好的解决方案会有很多杂活需要处理。 四、MQ 事务消息 有一些第三方的MQ是支持事务消息的比如RocketMQ他们支持事务消息的方式也是类似于采用的二阶段提交但是市面上一些主流的MQ都是不支持事务消息的比如 RabbitMQ 和 Kafka 都不支持。 以阿里的 RocketMQ 中间件为例其思路大致为 第一阶段Prepared消息会拿到消息的地址。 第二阶段执行本地事务第三阶段通过第一阶段拿到的地址去访问消息并修改状态。 也就是说在业务方法内要想消息队列提交两次请求一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息这时候发现了Prepared消息它会向消息发送者确认所以生产方需要实现一个check接口RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。 遗憾的是RocketMQ并没有 .NET 客户端。有关 RocketMQ的更多消息大家可以查看这篇博客 优点 实现了最终一致性不需要依赖本地数据库事务。 缺点 实现难度大主流MQ不支持没有.NET客户端RabbitMQ事务消息部分代码也未开源。 五、Sagas 事务模型 Saga事务模型又叫做长时间运行的事务Long-running-transaction, 它是由普林斯顿大学的H.Garcia-Molina等人提出它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。你可以在这里看到 Sagas 相关论文。 我们这里说的是一种基于 Sagas 机制的工作流事务模型这个模型的相关理论目前来说还是比较新的以至于百度上几乎没有什么相关资料。 该模型其核心思想就是拆分分布式系统中的长事务为多个短事务或者叫多个本地事务然后由 Sagas 工作流引擎负责协调如果整个流程正常结束那么就算是业务成功完成如果在这过程中实现失败那么Sagas工作流引擎就会以相反的顺序调用补偿操作重新进行业务回滚。 比如我们一次关于购买旅游套餐业务操作涉及到三个操作他们分别是预定车辆预定宾馆预定机票他们分别属于三个不同的远程接口。可能从我们程序的角度来说他们不属于一个事务但是从业务角度来说是属于同一个事务的。 他们的执行顺序如上图所示所以当发生失败时会依次进行取消的补偿操作。 因为长事务被拆分了很多个业务流所以 Sagas 事务模型最重要的一个部件就是工作流或者你也可以叫流程管理器Process Manager工作流引擎和Process Manager虽然不是同一个东西但是在这里他们的职责是相同的。在选择工作流引擎之后最终的代码也许看起来是这样的 SagaBuilder saga SagaBuilder.newSaga(trip).activity(Reserve car, ReserveCarAdapter.class) .compensationActivity(Cancel car, CancelCarAdapter.class) .activity(Book hotel, BookHotelAdapter.class) .compensationActivity(Cancel hotel, CancelHotelAdapter.class) .activity(Book flight, BookFlightAdapter.class) .compensationActivity(Cancel flight, CancelFlightAdapter.class) .end().triggerCompensationOnAnyError();camunda.getRepositoryService().createDeployment() .addModelInstance(saga.getModel()) .deploy(); 这里有一个 C# 相关示例有兴趣的同学可以看一下。 优缺点这里我们就不说了因为这个理论比较新目前市面上还没有什么解决方案即使是 Java 领域我也没有搜索的太多有用的信息。 分布式事务解决方案CAP 上面介绍的那些分布式事务的处理方案你在其他地方或许也可以看到但是并没有相关的实际代码或者是开源代码所以算不上什么干货下面就放干货了。 在 .NET 领域似乎没有什么现成的关于分布式事务的解决方案或者说是有但未开源。具笔者了解有一些公司内部其实是有这种解决方案的但是也是作为公司的一个核心产品之一并未开源... 鉴于以上原因所以博主就打算自己写一个并且开源出来所以从17年初就开始做这个事情然后花了大半年的时间在一直不断完善就是下面这个 CAP。 Github CAP这里的 CAP 就不是 CAP 理论了而是一个 .NET 分布式事务解决方案的名字。 详细介绍 http://www.cnblogs.com/savorboard/p/cap.html 相关文档 http://www.cnblogs.com/savorboard/p/cap-document.html 夸张的是这个解决方案是具有可视化界面Dashboard的你可以很方面的看到哪些消息执行成功哪些消息执行失败到底是发送失败还是处理失败一眼便知。 最夸张的是这个解决方案的可视化界面还提供了实时动态图表这样不但可以看到实时的消息发送及处理情况连当前的系统处理消息的速度都可以看到还可以看到过去24小时内的历史消息吞吐量。 最最夸张的是这个解决方案的还帮你集成了 Consul 做分布式节点发现和注册还有心跳检查你随时可以看到其他的节点的状况。 最最最夸张的是你以为你看其他节点的数据要登录到其他节点的Dashboard控制台看错了你随便打开其中任意一个节点的Dashboard点一下就可以切换到你想看的节点的控制台界面了就像你看本地的数据一样他们是完全去中心化的。 你以为这些就够了不远远不止 CAP 同时支持 RabbitMQKafka 等消息队列 CAP 同时支持 SQL Server, MySql, PostgreSql 等数据库 CAP Dashboard 同时支持中文和英文界面双语言妈妈再也不用担心我看不懂了 CAP 提供了丰富的接口可以供扩展什么序列化了自定义处理了自定义发送了统统不在话下 CAP 基于MIT开源你可以尽管拿去做二次开发。记得保留MIT的License 这下你以为我说完了 不 你完全可以把 CAP 当做一个 EventBus 来使用CAP具有优秀的消息处理能力不要担心瓶颈会在CAP那是永远不可能 因为你随时可以在配置中指定CAP处理的消息使用的进程数 只要你的数据库配置足够高... 说了这么多口干舌燥的你不 Star 一下给个精神上的支持说不过去吧 ^_^ 2号传送门 https://github.com/dotnetcore/CAP 不 Star 也没关系我选择原谅你~ 总结 通过本文我们了解到两个分布式系统的理论他们分别是CAP和BASE 理论同时我们也总结并对比了几种分布式分解方案的优缺点分布式事务本身是一个技术难题是没有一种完美的方案应对所有场景的具体还是要根据业务场景去抉择吧。 然后我们介绍了一种基于本地消息的的分布式事务解决方案CAP。 相关文章 谷歌发布的首款基于HTTP/2和protobuf的RPC框架GRPC 拥抱.NET Core跨平台的轻量级RPCRabbit.Rpc 基于DotNet Core的RPC框架(一) DotBPE.RPC快速开始 基于.NET CORE微服务框架 -surging的介绍和简单示例 开源 剥析surging的架构思想 基于.NET CORE微服务框架 -谈谈surging的服务容错降级 我眼中的ASP.NET Core之微服务 .NET Core 事件总线,分布式事务解决方案CAP CAP 介绍及使用【视频】 分布式事务,EventBus 解决方案:CAP【中文文档】 原文地址http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
