分布式事务

一、简介 与分布式事务TCC一样，目的都是为了在各个服务中正常使用事务。和TCC相比，Saga没有“预留”动作，操作都是直接提交到库。其中： 每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果 既然Saga的操作都是直接提交到库中，那么当后续的服务操作失败时，我们需要一种方法将已被改变的值更改为之前的状态。 为此Saga定义了两种恢复策略： backward recovery：向后恢复，补偿所有已完成的事务，如果任一子事务失败，则撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。 forward recovery：向前恢复，重试失败的事务，假设每个子事务最终都会成功。适用于必须要成功的场景，此处不需要补偿事务。 显然，向前恢复没有必要提供补偿事务，如果你的业务中，子事务（最终）总会成功，或补偿事务难以定义或不可能，向前恢复更符合你的需求。 注意事项： 对于服务来说，实现Saga有以下这些要求： Ti和Ci是幂等的。假设在执行Ti的时候超时了，如果采用重传策略则会再次发送Ti，那么就有可能出现Ti被执行了两次，所以要求Ti幂等。而如果Ci也超时了，就会尝试再次发送Ci，那么就有可能出现Ci被执行两次，所以要求Ci幂等。 Ci必须是能够成功的，如果无法成功则需要人工介入

对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题，但话又说回来了，既然逃避不掉，那我们就要想想应对措施，今天我们就一起讨论一下常见的并发和同步吧。 首先为了更好的理解并发和同步，我们需要首先明白两个重要的概念： 同步和异步 同步和异步的区别和联系 所谓同步，就是一个线程执行一个方法或函数的时候，会阻塞其它线程，其他线程要等待它执行完毕才能继续执行。 异步，就是多个线程之间没有阻塞，多个线程同时执行。 通俗一点来说，同步就是一件事一件事的做，异步就是做一件事，不影响做其他事情。 例如：吃饭和说话，只能一件一件的来，因为只有一张嘴。 但是吃饭和听音乐是异步的，可以一起进行，因为听音乐并不影响我们吃饭。 对于Java程序员来说，Synchronized最为熟悉了，如果它作用于一个类的话，那么就是一个线程访问类的方法时，其他线程就会阻塞，相反，如果没有这个关键字来修饰的话，不同线程就可以在同一时间访问同一个方法，这就是异步。 脏读和不可重复读 脏读 脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这是，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读取的这个数据是脏数据(Dirty Data)

1：分布式事物的理解： 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，分布式事务需要保证这些小操作要么全部成功，要么全部失败;本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2：分布式失误产生的原因： a）数据库分库分表; 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 b)应用SOA化； 就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心等,对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了。 3）分布式的使用场景： 支付：一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败，并且卖家账户对应卖家数据库

分布式事务简介： 对于分布式系统，必然会存在分布式事务，如果对分布式事务一无所知必然会很坑，所以起码要知道有哪些方案，一般怎么来做，每个方案的优缺点是什么，这一点要清楚。 现在，分布式系统变成了标配，而分布式系统带来的分布式事务也成了标配了。因为我们做系统肯定要用事务的，如果是分布式系统，肯定要用分布式事务了吧，先不说有有没有搞过，起码得明白有哪几种方案，每种方案可能有什么坑的存在？eg：TCC方案的网络问题 ，XA方案的一致性问题。 分布式事务的实现主要有以下5种方案： 1.XA方案（两阶段提交） 2.TCC方案 3.本地消息表 4.可靠消息最终一致性 5.最大努力通知方案 两阶段提交方案/XA方案 所有XA方案，就是 两阶段提交 ，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库回复都ok的话，那就ok，正式提交事务，在各个数据库上执行操作，如果任何其中一个数据库回答不ok，那么就回滚事务。 这种分布式方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于spring+JTA就可以搞定，自己随便找个demo看一下。 这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的操作，是不合规的。现在说下微服务

1.ACID特性 数据库管理系统中事务(transaction)的四个特性： 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 1、原子性 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么全部成功，要么全部失败。 2、一致性 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。 3、隔离性 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。 4、持久性 持久性，意味着在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。 2.CAP理论 CAP理论，指的是在一个分布式系统中，不可能同时满足Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能满足其中的两项。 1、一致性： 指数据在多个副本之间是否能够保持一致的特性。当执行数据更新操作后，仍然可以保证系统数据处于一致的状态。 2、可用性： 系统提供的服务必须一直处于可用的状态。对于用户的每一个操作请求总是能够在“有限的时间内”返回结果。这个有限时间是系统设计之初就指定好的系统运行指标

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤：从 A 账户取 100 元。存入

无论是云计算、大数据还是互联网公司的各种应用，其后台基础设施的主要目标都是构建低成本、高性能、可扩展、易用的分布式存储系统。 大规模分布式存储系统的定义如下：分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。 几个特点： （1）可扩展：分布式存储系统可以扩展到几百台甚至上千台的集群规模，而且，随着集群规模的增长，系统整体性能表现为线性增长 （2）低成本：自动容错、自动负载均衡机制使其可以构建在普通PC机之上。另外，线性扩展能力也使得增加、减少机器非常方便，可以实现自动运维。 （3）高性能：针对整个集群还是单台服务器，都要求分布式存储系统具备高性能。 （4）易用：分布式存储喜提需要能够提供易用的对外接口，另外，也要求具备完善的监控、运维工具。 分布式存储数据需求比较复杂，大体可以分为三类： （1）非结构化数据 （2）结构化数据 （3）半结构化数据 不同的分布式存储系统适合处理不同类型的数据，将分布式存储系统分为四类： （1）分布式文件系统：互联网应用需要存储大量的图片，视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob数据（Binary Large Object二进制大对象） 分布式文件系统存储三种类型的数据：Blob对象，定长块，大文件 （2）分布式键值系统：存储关系检点的半结构化数据

作者：张乘辉 前言 在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，在某些服务出现故障时也不会影响其它服务的正常运行。总之，微服务在业务的高速发展中带给我们越来越多的优势，但是微服务并不是十全十美，因此不能盲目过度滥用，它有很多不足，而且会给系统带来一定的复杂度，其中伴随而来的分布式事务问题，是微服务架构体系下必然需要处理的一个痛点，也是业界一直关注的一个领域，因此也出现了诸如 CAP 和 BASE 等理论。 在今年年初，阿里开源了一个分布式事务中间件，起初起名为 Fescar，后改名为 Seata，在它开源之初，我就知道它肯定要火，因为这是一个解决痛点的开源项目，Seata 一开始就是冲着对业务无侵入与高性能方向走，这正是我们对解决分布式事务问题迫切的需求。 分布式事务解决的方案有哪些？ 目前分布式事务解决的方案主要有对业务无入侵和有入侵的方案，无入侵方案主要有基于数据库 XA 协议的两段式提交（2PC）方案，它的优点是对业务代码无入侵，但是它的缺点也是很明显：必须要求数据库对 XA 协议的支持，且由于 XA 协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，因此它性能很差，它的存在相当于七伤拳那样“伤人七分，损己三分”

mysql存储引擎概述 什么是存储引擎？ MySQL中的数据用各种不同的技术存储在文件（或者内存）中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。 例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)。 这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型)。 MySQL默认配置了许多不同的存储引擎，可以预先设置或者在MySQL服务器中启用。你可以选择适用于服务器、数据库和表格的存储引擎，以便在选择如何存储你的信息、如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性。 选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因。其它 数据库系统 (包括大多数商业选择)仅支持一种类型的 数据存储 。 遗憾的是，其它类型的数据库解决方案采取的“一个尺码满足一切需求”的方式意味着你要么就牺牲一些性能，要么你就用几个小时甚至几天的时间详细调整你的数据库。使用MySQL，我们仅需要修改我们使用的存储引擎就可以了 mysql支持哪些存储引擎？ 　　mysql5

一、消息事务 其实很多场景下，我们“发消息”这个过程，目的往往是 通知另外一个系统或者模块去更新数据 ，消息队列中的“事务”，主要解决 消息生产者和消息消费者的数据一致性问题 。 用户在电商APP上购物时，先把商品加到购物车里，然后几件商品一起下单，最后支付，完成购物流程。 这个过程中有一个需要用到消息队列的步骤，订单系统创建订单后，发消息给购物车系统，将已下单的商品从购物车中删除。因为从购物车删除已下单商品这个步骤，并不是用户下单支付这个主要流程中必要的步骤，使用消息队列来异步清理购物车是更加合理。 对于订单系统，它创建订单的过程实际执行了2个步骤的操作： 在订单库中插入一条订单数据，创建订单； 发消息给消息队列，消息的内容就是刚刚创建的订单 对于购物车系统： 订阅相应的主题，接收订单创建的消息，然后清理购物车，在购物车中删除订单的商品。 来源： https://www.cnblogs.com/chjxbt/p/11412727.html