分布式事务

简介 关于CAP理论看了很多博客，但是概念仍然很模糊，很幸运看到了几篇比较有感触的文章，做以总结和梳理。相关文章的原作者已经很难找到，因此此处就不一一列举，感谢他们。 CAP针对的是分布式系统，根据分布式系统的各种特性和场景总结出了的三个指标 一、分布式系统的三个指标 1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。 Consistency Availability Partition tolerance 它们的第一个字母分别是 C、A、P。 Eric Brewer 说，这三个指标不可能同时做到，最多只能满足其中的两个。这个结论就叫做 CAP 定理。 二、Partition tolerance（分区容忍性） 分布式系统中会有多个独立的服务，而且一般情况下，不同服务位于不同的物理服务器。 上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。 一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。 三、Consistency Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。 接下来

上一篇文章讲述的是抛弃A，保证CP的刚性分布式事务解决方案，这一篇介绍柔性分布式事务解决方案。 柔性事务遵循BASE理论，抛弃C，保证AP，以最终一致性来代替强一致性，柔性分布式事务解决方案中MQ承担非常重要的角色。 1.本地化消息表 A B两个分布式应用，各自有一个本地化消息表。 A中的业务和消息处于同一个本地事务中，也就意味着A的事务提交之后，消息表中也存放了这条消息。存完之后A系统会把这条消息发送到MQ.B接收到消息之后会写到本地消息表，同时执行业务逻辑.B应用也一样，业务和表处于同一个事务中。这里会有一个幂等操作，如果这条消息之前已经处理过，B就会回滚事务。B业务逻辑执行成功之后会更新消息的状态，同时更新A表的消息状态。 如果B系统处理失败了，那么就不会更新消息表状态，那么此时A系统会定时扫描自己的消息表，如果有没处理的消息，会再次发送到MQ中去，让B再次处理 这个方案保证了最终一致性，哪怕B事务失败了，但是A会不断重发消息，直到B那边成功为止 2.基于支持事务的MQ 上述方法有个比较不好地方，就是需要各个应用在本地建一个表，和业务耦合度比较高。有没有不需要本地建表的方法呢? 市面上有一些MQ支持事务的，比如RocketMQ。 在介绍这种方法之前先解释一下RocketMQ的几个名词 prepare消息 又名Half Message，半消息，标识该消息处于"暂时不能投递"状态

导读：在上篇文章中介绍了分布式事务项目的基本原理和工程组件，我们了解到了分布式事务的理论知识。处于实战的经验，我们将理论知识使用到实际项目中。所以我们将借助idea中maven工程 来实战我们的项目。 回到正文： 在上篇文章中我们已经把需要的准备工作做好了。现在我们需要将如何实现分布式3PC事务提交锁。 先睹为快 首先我们先来体验一下事务提交锁的过程，在本项目中我们将在Windows环境下搭建redis环境和zookeeper环境。下面就是我们只需一段分布式加锁程序的过程。一段执行锁发生异常的行为： 定义事物锁的类型： 我们使用分布式事务锁的时候我们需要提供如下几种类型的锁： 1：写锁，WRITE 2：读锁，READ 3：独占写锁，到时间释放：WRITE_TIME 4：强制时间锁，无论获取锁成功，强制时间锁， 到时间时间释放，FORCE_WRITE_TIME 更具上面分析我们将定义一个枚举类来枚举上面所需要的锁。NettyTransactionLockType.java package com.twjitm.transaction.transaction.enums; /** * 事物锁类型 * * @author twjitm- [Created on 2018-08-27 11:50] * @jdk java version "1.8.0_77" */ public enum

回想12年左右刚开始接触Nosql，各种Nosql数据库如雨后春笋般出现，如MongoDB、Redis、Hadoop、CouchDB等等，其中有一篇CAP理论文章非常火。到现在CAP、ACID、BASE各种概念，但分布式事务是必须面对的问题。 ACID 数据库管理系统中事务(transaction)的四个特性 原子性（Atomicity） 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。 一致性（Consistency） 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。 隔离性（Isolation） 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。（ 数据库事务隔离级别 ） 持久性（Durability） 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，即使数据库发生故障也不应该对其有任何影响。 所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。 单实例关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足ACID的特性。 CAP理论 Consisteny（一致性） 一致性的要求是指，对于任何客户端来说，每次的读操作，都能获得最新的数据。即，当有客户端向A节点写入了新数据之后

【背景】 随着单体应用的缺陷日益明显，越多越多的公司都从传统的单体应用模式向新型的分布式应用模式转变。 实际上，在分布式应用带来巨大优势的同时，也伴随着各种挑战。例如，系统容错、网络延迟和分布式事务等。 本篇博客开始，将会对分布式事务做一系列学习总结。从本篇博客，我们可以了解到什么是分布式事务，关于分布式事务的相关理论以及处理分布式事务的解决方案。 【本地事务】 在没有接触分布式应用前，我们接触到的事务一般都是本地事务，即在单个数据库并且限制在单个进程内的事务。本地事务不涉及多个数据源。 若我们的系统使用了spring，一般加上@Transition注解即可保证事务正常运行。但如果是分布式系统应用下，若操作涉及不同的数据库，这样本地事务就失效了，从而就涉及到了分布式事务。 【分布式事务】 1. 什么是分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. 分布式事务的产生原因 从原来的单体应用到分布式应用的转变，便意味着从以前的一个系统到多个服务共同组成一个系统的转变。 如一个电商系统，拆分为订单

近期公司项目基于微服务架构需要涉及到实现一套分布式事务。经过几天在网上查阅资料发现大部分文章只是讲解了具体的其中一个模型。因此在这里做一个总结+自己的一些感悟和看法。 1.CAP理论 CAP理论本身并不是一套和事务相关的理论，而是用来解释分布式系统的理论。但是用来分析分布式事物的边界非常适合。关于CAP理论，可以查看阮一峰大神的这篇文章： CAP定理的含义 CAP理论一个核心论证就是P(分区容错性)作为一个分布式系统是肯定包含的。因此实际实现只是在CP和AP之间做抉择。 CP：为了保证一致性和分区容错性，那么肯定会丧失一部分可用性。 AP：为了保证可用性和分区容错性，那么肯定会丧失一部分一致性。 2.ACID原则 ACID原则是用来描述一个事务应该包含的特性。原子性、一致性、隔离性、持久性。这个原则实际上和CAP理论是相悖的。 3.刚性事务、CP模式、XA协议 我们来假设一个简单的支付场景， 生成订单--->扣用户积分--->核销优惠劵--->修改订单状态 。这里涉及三个系统，订单系统、用户积分系统、优惠劵系统。那么如果我们要保证事务的一致性，我们在其中的每一步都会将资源锁定，然后只有在最终事务全部完成后，我们才能释放锁。那么在整个事务周期内我们的功能必定是处于不可用状态。这也正符合 CP定义 。这么做的事务确实可以保证事务的ACID原则，但是因为锁定时间长、锁粒度大(锁定资源多)

Java Web系列文章汇总贴: Java Web知识总结汇总 分布式事务基本理论 基本概念 通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库（可以是不同的应用对应的数据库）。对数据库的操作发生在系统的各处但必须全部被提交或回滚 。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么。因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）映射到全局事务中。 2PC、3PC基本概念 2PC,3PC主要是基于分布式事务的分布式一致性算法（因为分布式事务也可能会导致数据的不一致问题，这跟副本的不一致性从大类上看是都归于数据的不一致）。 在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是

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

分布式事务 分布式理论 单个数据库的性能产生瓶颈的时候，我们可能对数据库进行分区，这里所说的分区是指物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID会导致我们的系统变得很差，这个时候我们需要引入CAP原则。 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) ： 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。 [了解] 数据库支持2PC，又叫XA Transactions,MySQL5.5、SQL Server2005、Oracle7开始支持。 其中，XA是一个两阶段提交协议，该协议分为以下两个阶段： ·第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。 ·第二阶段：事务协调器要求每个数据库提交数据。 如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在次数据库中的那部分信息

一、概述 在微服务架构下，虽然我们会尽量避免分布式事务，但是只要业务复杂的情况下这是一个绕不开的问题，如何保证业务数据一致性呢？本文主要介绍同步场景下使用 Seata 的 AT模式 来解决一致性问题。 Seata 是 阿里巴巴 开源的 一站式分布式事务解决方案 中间件，以 高效 并且对业务 0 侵入 的方式，解决 微服务 场景下面临的分布式事务问题 二、Seata介绍 整体事务逻辑是基于 两阶段提交 的模型，核心概念包括以下3个角色： TM ：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM ：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC ：事务的协调者seata-server，用于接收我们的事务的注册，提交和回滚。 目前的 Seata 有两种模式可使用分别对应不同业务场景 2.1. AT模式 该模式适合的场景： 基于支持本地 ACID 事务的关系型数据库。 Java 应用，通过 JDBC 访问数据库。 一个典型的分布式事务过程： TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID 。 XID 在微服务调用链路的上下文中传播。 RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。 TM 向 TC 发起针对 XID 的全局提交或回滚决议。 TC 调度 XID