分布式事务

作者 | 晓土 阿里巴巴高级工程师 姊妹篇阅读推荐 ： 《 云原生时代，分布式系统设计必备知识图谱（内含22个知识点） 》 导读： 本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 进化有着立体的认识；从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，彻底打破传统的开发方式，解放了新一代的生产力。 分布式系统知识体系大图 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构

最近做项目使用到了分布式事务，下面这篇文章将给大家介绍一下对分布式事务的一些见解，并讲解分布式事务处理框架TX-LCN的执行原理，初学入门，错误之处望各位不吝指正。 什么情况下需要使用分布式事务？ 使用的场景很多，先举一个常见的：在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。 打个比方：电商平台有一个客户下订单的业务逻辑，这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），示意图如下： 如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致现象。 所以在类似的场合下我们要使用分布式事务，保证数据的一致性。 分布式事务的解决思路 引入：mysql中的两阶段提交策略 在谈分布式事务的解决思路之前，我们先来看看单一数据源是如何做事务处理的，我们可以从中获取一些启发。 我们以mysql的InnoDB引擎为例，由于mysql中有两套日志机制，一套是存储层的redo log，另一套是server层的binlog，每次更新数据都要对两个日志进行更新。为了防止写日志时只写了其中一个而没有写另外一个，mysql使用了一个叫 两阶段提交 的方式保证事务的一致性。具体是这样的：

一、分布式锁 1、什么是分布式锁？ 场景1：常规的我们多线程访问同一代码块的时候，为了保证同一时间只能 由一个线程访问，保证数据安全一致性，通常我们使用synchronized关键字来对方法加锁，以达到保证数据安全性。 场景2：现在越来越多的项目，为了追求性能与高并发，采用了soa架构，微服务架构，于是就会出现多个模块单独的服务。这个时候呢就会有一个问题，如何保证多个节点的现场同步执行呢？ 这种情况呢，就会用到了分布式锁。 2、分布式锁的解决方案与实现有哪些呢？ 1、数据库解决方案思路： a.数据库建一张表，字段方法名并且作为唯一性，当一个方法执行时插入，则相当于获得锁，其他线程将无法访问，方法执行完则释放锁。 但是上面这种存在问题： 1、数据库单点，出现故障则将导致系统不可用。 2、没有失效时间，一旦操作方法异常，导致一直没有解锁，也将导致其他不可用用。 b.使用select * from user u where username = '' for update 来对记录加上排他锁。操作完成后使用 commit命令释放锁。 2、基于缓存实现： 通常有 Memcached、Redis实现等，以下以Redis实现分布式锁为例 思路：主要用到的redis函数是setnx()，这个应该是实现分布式锁最主要的函数。首先是将某一任务标识名（这里用Lock:order作为标识名的例子

课程介绍: 分布式事务是一个绕不过去的挑战！微服务架构本质上就是分布式服务化架构，微服务架构的流行，让分布式事务问题日益突出！尤其是在订单业务、资金业务等系统核心业务流程中，一定要有可靠的分布式事务解决方案来保证业务数据的可靠性和准确性。 为了解决大家在实施分布式服务化架构过程中关于分布式事务问题的困扰，本教程将基于支付系统真实业务中的经典场景来对“可靠消息的最终一致性方案”、“TCC两阶段型方案”和“最大努力通知型方案”这3种柔性事务解决方案进行具体设计实现和详细讲解。 本教程提供的分布式事务解决方案的设计思路在所有微服务架构项目中都适用，与编程语言无关，教程中会重点讲解方案的设计思路。 教程中的样例项目基于龙果学院开源的微支付系统进行实现，使用Dubbo作为服务化框架，教程中所实现的分布式事务解决方案在Java体系中的微服务架构系统都能通用，与具体的开发框架无关。 教程样例项目中用到的技术及相应的环境： Dubbo、Spring、SpringMVC、MyBatis、Druid、JDK7（或JDK8）、MySQL5.6、Tomcat 课程大纲: 第1节课程介绍 第2节解决方案的效果演示（结合支付系统真实应用场景） 第3节常用的分布式事务解决方案介绍 [免费观看] 47分钟 第4节消息发送一致性（可靠消息的前提保障）20分钟 第5节消息发送一致性的异常流程处理16分钟

#0 系列目录# 分布式事务 【分布式事务系列一】提出疑问和研究过程 【分布式事务系列二】Spring事务管理器PlatformTransactionManager 【分布式事务系列三】Spring的事务体系 【分布式事务系列四】分布式事务的概念 【分布式事务系列五】jotm的分布式案例 【分布式事务系列六】jotm分布式事务源码分析 【分布式事务系列七】Atomikos的分布式案例 【分布式事务系列八】JTA深度历险-原理与实现 【分布式事务系列九】聊聊分布式事务 #1 什么是事务# 事务就是一个会话过程中，对上下文的影响是一致的，要么所有的更改都做了，要么所有的更变都撤销掉。就要么生，要么死。没有半死不死的中间不可预期状态。 事务是为了保障业务数据的完整性和准确性的 。 #2 分布式事务# 分布式事务，常见的两个处理办法就是 两段式提交和补偿 。 两段式提交典型的就是XA ，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉大家，一起提交，大家都提交了。 补偿比较好理解，先处理业务 ，然后定时或者回调里，检查状态是不是一致的，如果不一致采用某个策略，强制状态到某个结束状态（一般是失败状态），然后就世界太平了。典型的就是冲正操作。 比如对数据库来说，有redo日志的 。如果某个数据库这时候宕机了，那么它重启的时候，先执行检查

随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。 为了解决这样一系列问题，大型网站的 架构 也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。本文主要介绍关于分布式事务，二阶段提交和三阶段提交。 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和 算法 。其中比较著名的有二阶提交协议、三阶提交协议和Paxos算法。 分布式事务 分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚） 在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲

在说分布式事务之前，先回顾下事务的相关知识点。 事务 概念 事务指的是一系列数据库操作，它是保证数据库正确性的基本逻辑单元，拥有ACID四个特性：原子性、一致性、隔离性与持久性。 举个例子，下面这两种组成情况都叫做事务： 1.由单个操作序列（一条SQL语句）组成的事务 select * from test; 2.由多个操作序列（SQL语句）组成的事务 select * from test where id = 1; update test(id, name) set name = 'john' where id = 1; 当然，如果我们没有显示声明事务的话，数据库则会给我们自动地划分事务，对于MySQL来说，没有显示声明事务，则一条SQL语句就是一个事务，执行完便会自动提交。 一个事务由开始标识(begin_transaction)、数据库操作和结束标识(commit或rollback)三部分组成。如下图所示： 关于上图的相关说明如下： 事务开始：begin_transaction，说明事务的开始； 数据库上的操作：表现为一条或多条SQL语句； 事务提交：commit_transaction，提交事务操作，操作生效； 事务回滚：rollback_transaction，事务取消，操作废弃。 特性 事务是对数据库的一系列操作，是保证数据库正确性的基本逻辑单元

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 事务的ACID特性 原子性 一致性 隔离性 持久性 消息事务+最终一致性 CC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。 来源： https://www.cnblogs.com/Yanss/p/11676223.html

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。 现代的一些处理框架