分布式事务

https://github.com/OpenSagas-csharp/servicecomb-pack-csharp Saga基本使用指南 使用前置条件说明 如果还有同学对Saga还不甚了解的同学,可以参考Saga官方中文地址 地址 ,同时可以参考此项目贡献者之一的 WithLin 的一篇中文说明文章,该地址如下: 地址 ,文章由浅入深的讲述了分布式事务在微服务场景下的重要性,以及Saga对分布式事务的大致实现方式和后续的思考 必须 你需要可用的一个本地或者远程的数据库(mysql或者postpresql)作为Saga持久化分布式事务事件的持久化存储,当然只要官方支持的Database Provider即可,具体idea数据库配置如下图,注意数据库的名字与您真实数据库名一致 必须 成功启动alpha-server,导致环境搭建以及部署颇为麻烦,后期官方将会提供image上传docker hub提供给大家使用,启动成功参考下图 可选 同时saga提供了UI可视化界面,直接idea中启动saga-web即可 支持docker-compose:根目录提供了一个dockercompose文件,只需要在工程的根目录下执行docker-compose up -d 即可，上面的操作可以给感兴趣的调试环境的搭建。 开始玩转分布式事务Saga 克隆当前项目

给予消息队列实现分布式事务 场景: 订单系统产生订单,购物车系统减购物车中的商。 实现思路 : 订单系统在消息队列上开启一个事务（没有创建订单）。 订单系统给消息服务器发送一个“半消息”，这个半消息不是说消息内容不完整，它包含的内容就是完整的消息内容，半消息和普通消息的唯一区别是，在事务提交之前，对于消费者来说，这个消息是不可见的。 半消息发送成功后，订单系统就可以执行本地事务了，在订单库中创建一条订单记录，并提交订单库的数据库事务。 然后根据本地事务的执行结果决定提交或者回滚事务消息。如果订单创建成功，那就提交事务消息，购物车系统就可以消费到这条消息继续后续的流程。如果订单创建失败，那就回滚事务消息，购物车系统就不会收到这条消息。 橙色和绿色分别是两个事务。 问题: 步骤4事务提交失败；这时候订单系统本地事务已提交尔购物车系统没有收到消息，造成数据不一致。 如何解決消息队列事务提交过程出现的异常: kafka会直接抛出异常用户自行处理; 在RocketMQ中的事务实现中,增加了 事务反查 的机制来解决事务消息提交失败的问题 , RocketMQ的Broker没有收到提交或者回滚的请求,Broker会定期去producer上反查这个事务对应的本地事务的状态,然后根据反查结果决定提交或者回滚这个事务。 为了支持事务反查机制

1、概述 情景描述： dubbo服务A ：支付接口服务 dubbo服务B ：订单状态更新 正常流程，首先调用 支付接口，支付成功后，再调用dubbo服务B更新订单状态；但是如果在调用dubbo服务B时失败，此时dubbo服务A中数据已无法回滚（事务已提交），此时该如何进行处理? 方案一： 手动编写dubbo服务A回滚代码，在dubbo服务B调用失败时，进行该回滚代码调用，此方案只使用简单业务场景、冗余代码多。 方案二： 使用JTA分布式事务，但这样不好的就是代码入侵性高以及性能问题。（本人也没有用过，网上这么讲的）。 方案三： 结合MQ消息中间件实现的可靠消息，来到达数据最终一致性（CAP理论）。 2、折中方案 方案一不理想，方案二、三相关技术没具体接触过。 下图是项目中遇到的折中方案： 也就是说“dubbo服务A”即是提供者也是消费者（dubbo服务B的调用），只有在"dubbo服务B"调用成功的情况下才会对“dubbo服务A”事务提交。 局限： 即是生产者又是消费者的dubbo服务，只能进行“唯一”dubbo服务调用。 而这个“单一”dubbo服务调用只能放在最后执行。 三个服务调用情况就是如下 3、收尾 至此，关于分布式服务框架-dubbo总结完毕！ 额外提下，之前demo工程中主键id采用的数据库自增，在“分布式”局限性 分布式服务中，重试机制下容易造成数据重复。

由于数据量的巨大，大部分Web应用都需要部署很多个数据库实例。这样，有些用户操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性，经典的方法是使用两阶段提交协议。 长期以来，分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵，很多人都不敢越雷池一步，想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了，开发者更是沉醉其中，不去考虑分布式事务是否给系统带来了伤害。 事实上，有所得必有所失，分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下，分布式事务才能够顺利完成，只要有一个工作不正常，整个事务就不能完成。这样，系统的可用性就相当于参加分布式事务的各实例的可用性之积，实例越多，可用性下降越明显。从性能和可伸缩性角度看，首先是事务的总持续时间通常是各实例操作时间之和，因为一个事务中的各个操作通常是顺序执行的，这样事务的响应时间就会增加很多；其次是一般Web应用的事务都不大，单机操作时间也就几毫秒甚至不到1毫秒，一但涉及到分布式事务，提交时节点间的网络通信往返过程也为毫秒级别，对事务响应时间的影响也不可忽视。由于事务持续时间延长，事务对相关资源的锁定时间也相应增加

1. 从RDBMS到NoSQL的架构演化 互联网时代背景下大机遇，为什么用nosql 1 单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小 一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 如果出现了上述1 or 3个上述瓶颈，架构开始演化到下一个阶段： 2 Memcached(缓存)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展

▲扫码报名活动 数人云11月Meetup报名开启， 看中西方大神如何论道云原生与微服务！ 数人云 上几天给大家分享了：《踢开绊脚石：微服务难点之服务调用的解决方案》剖析了微服务的难点之一：服务调用的解决方案。今天再来跟大家聊聊微服务的另外一个难点：数据。 在尝试使用微服务架构的因由中，最主要的是允许团队能够以不同的速度在系统的不同部分进行工作，而且尽量将影响团队的相关因素最小化。因此，我们希望团队能够自治，做出关于实现和运营服务最好的决策，并且可以自由地进行更改。 为了获得这种自主权，需要“摆脱依赖”，很多人在某种程度上都引用了这句话，因为“每个微服务都应该拥有和控制自己的数据库，而不是两个服务去共享一个数据库。”这种理念是合情合理的，不要在服务之间共享一个数据库是因为会遇到读/写模式冲突、数据模型冲突、协调性问题等等。 当构建微服务时，如何安全地将数据库分切成多个小的数据库？首先对于企业级构建微服务，需要明确以下内容： 域是什么？它实现了什么 事物边界在哪里？ 微服务如何跨越边界进行通信？ 如果将数据库打开，会怎样？ 什么是域 这似乎在很多地方都被忽视了，但在互联网公司如何实践微服务和传统企业如何（或者可能因为忽视了这一点而失败）实现微服务之间存在的巨大差异。 在构建微服务之前，以及它使用的数据（产品/消费等）的原因，需要对数据的表示有一个明确清晰的理解，例如

引言 这篇说说分布式事务的问题。企业现在的架构都由传统的架构转向了微服务架构，如下图所示: 那么，都不可避免的会遇到跨数据库调用的，分布式事务问题！ 目前，业内解决分布式事务问题，都基本不用JTA这种强一致性的解决方案，基本是采用如下两套方案 基于TCC的事务框架 消息队列 OK，你们先记住两点 (1)图中的服务A和服务B，如果是同步调用，要求一起成功，或者一起失败，那么此时应选用TCC的事务框架，这点我改天另写一篇，先挖坑！ (2)图中的服务A和服务B，如果是异步调用，比如服务C先调用服务A后，服务C不用管服务B的执行结果，直接返回，那么这种情况下，应选用消息队列！这篇文章重点讲！ 目前为止，大部分文章都讲的太复杂了。导致很多新人看完后于是看这篇文章前，你们先忘记你们在其他文章看到的概念，跟着博主的思路走！ 正文 先给大家套一个业务场景，也是很常见的一个异步调用场景: 支付宝往余额宝转钱 即将服务A假设为支付宝，服务B假设为余额宝。 于是呢，我们的支付宝往余额宝转100块钱是怎么做的呢？ 特别容易，借助消息队列即可，如下图所示 一致性解决 OK，上面这一版有一个致命的问题！如下所示 事务开始 (1)给支付宝账户zhangsan,扣100元 (2)将(给余额宝账户zhangsan,加100元)封装为消息，发送给消息队列 事务结束 敢问你，如何保证第一步和第二步是在同一个事务里完成的

简述 分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。 例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。 解决方案 在分布式系统中，要实现分布式事务，无外乎那几种解决方案。 一、两阶段提交（2PC） 两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 1. 运行过程 1.1 准备阶段 协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 1.2 提交阶段 如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。 2. 存在的问题 2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。 2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。 2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务

最近在找工作，总是会被问到分布式事务的问题。 被问到想吐，诚实的回答我们不做分布式事务，面试官好像又不满意，我不明白现在的人为什么都那么装呢？ 很多情况下出现事务的问题，很久也碰不了一次，如果出错了记录日志，定位，补偿不就完了。现在又没有强事务的分布式事务解决方案，都是弱事务，说白了就是靠代码逻辑实现最终一致。在业务代码里面夹杂着分布式事务的代码，真要出了问题，你怎么定位呢？ 分布式事务的解决方案 1.XA方案也叫做两阶段提交事务方案. 主要通过增加事务协调者，对事务进行全局管理。 第一个阶段： 发出“准备”命令，所有事务参与者接受指令后进行资源准备，锁准备，undo log准备。如果都返回“准备成功”，如果不能执行，返回终止。 第二个阶段 协调者接受到第一个阶段的回复 如果都是ok，则发出“提交”命令，所有参与者进行commit操作。如果都成功，则事务结束，如果有失败情况，协调者发出“回滚”命令，所有事务参与者利用undo log进行回滚（这个在2PC不存在）。J2EE对JTA就是两阶段提交的实现。 如果有不ok，则发出撤销，所有事物撤销本地资源的锁定等操作 2.TCC方案 1 Try 对各个服务的资源做检测,对资源进行锁定或者预留 2 Confirm 在各个服务中执行实际的操作 3 Cancel 如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿

1.XA XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。下图说明了事务管理器、资源管理器，与应用程序之间的关系： 图1.XA规范下的分布式事务各类参与者之间的关系 2.JTA 作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种： 1