分布式事务

ps.本文为《从Paxos到Zookeeper 分布式一致性原理与实践》笔记之一 ZooKeeper ZooKeeper曾是Apache Hadoop的一个子项目，是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等。 ZooKeeper是Google的Chubby一个开源的实现，由雅虎创建，是Hadoop和Hbase的重要组件。 ZooKeeper没有直接采用paxos算法，而是采用了一种被称为ZAB（Zookeeper Atomic Broadcast）的一致性协议 ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper可以保证如下分布式一致性特性 顺序一致性：从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中； 原子性：所有事务的请求结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么在整个集群中所有机器上都成功应用了某一个事务，要么都没有应用，没有中间状态； 单一视图：无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。 可靠性：一旦服务端成功应用了一个事务，并完成对客户端的响应

1 一致性 1.1 简述 一致性，是指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的 假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性： 全认同 : 所有N个节点都认同一个结果 值合法 : 该结果必须由N个节点中的过半节点提出 可结束 : 决议过程在一定时间内结束，不会无休止地进行下去 1.2 面临着的问题 消息传递异步无序 : 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序 节点宕机 : 节点持续宕机，不会恢复 节点宕机恢复 : 节点宕机一段时间后恢复，在分布式系统中最常见 网络分化 : 网络链路出现问题，将N个节点隔离成多个部分 拜占庭将军问题 : 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息 假设现实场景中也存在这样的问题： 周五 我：晚上下班吃鸡 周六凌晨 xc：好的 // 消息延迟 我：... --------------------------------- 我：晚上下班吃鸡 xc：No (两小时后) xc：No problem！ // 宕机节点恢复 我：… --------------------------------- 我：晚上下班吃鸡 … // 节点宕机 --------------------------------- 我：晚上下班吃鸡 cx:好，我们去大保健！ //

作者：h-松 链接：https://juejin.im/post/5d5569466fb9a06af629a9ab 分布式事务的挑战 在多个服务、数据库和消息代理之间维持数据的一致性的传统方式是采用分布式事务。分布式的事实标注是XA、XA采用了两阶段提交老保证事务中的所有参与方同时完成提交，或者失败时同时回滚。应用程序的整个技术栈需要满足XA标准。 许多新技术，包括NoSQLshujk ,liru MongoDB和Cassandra并不支持XA标准的分布式事务。同样，一些流行的消息代理如RabbitMQ和Apache Kafka也不支持分布式事务。如果你坚持在微服务中使用分布式事务，那么不得不放弃使用这些流行的数据库或消息代理。 saga 将跨越多个服务的每个业务事务作为一个SAGA实现。SAGA是一系列本地事务。每个本地事务更新数据库并发布消息或事件以触发SAGA中的下一个本地事务。如果本地事务由于违反业务规则而失败，那么SAGA将执行一系列补偿事务，以撤消前面的本地事务所做的更改。 有两种协调方式： 协同-每个本地事务发布触发其他服务中本地事务的域事件 编排-编排器（对象）告诉参与者要执行的本地事务 协同式 编排 saga这种模式有以下好处： 它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务 此解决方案有以下缺点： 编程模型更复杂。例如，开发人员必须设计补偿事务

1.1 mysql 架构 　　mysql 分为 server 层和存储引擎 1.1.1 server层 连接器：管理连接权限验证 查询缓存：命中缓存直接换回查询结果 分析器：分析语法 优化器：生成执行计划，选择索引 执行器：操作索引返回结果 1.1.2 存储引擎 存储引擎负责数据的存储和提取；其架构是插件式的。innodb 在 mysql5.5.5 版本开始成为 mysql 默认存储引擎。 各存储引擎比对： InnoDB：支持事务，支持外键，InnoDB 是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据，不支持全文索引。 MyISAM：不支持事物，不支持外键，MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的，查询效率上 MyISAM 要高于 InnnDB ，因此做读写分离的时候一般选择用 InnoDB 做主机，MyISAM 做从机 Memory：有比较大的缺陷使用场景很少；文件数据都存储在内存中，如果 mysqld 进程发生异常，重启或关闭机器这些数据都会消失。 1.1.3 sql 的执行过程 　　第一步客户端连接上 mysql 数据库的连接器，连接器获取权限，维持管理连接；连接完成后如果你没有后续的指令这个连接就会处于空闲状态

摘要：对于所有的分布式系统，我想事务一致性问题是极其非常重要的问题，因为它直接影响到系统的可用性。本文以下所述所要解决的问题是：对于入HBase和Solr的过程，如何保证HBase中写入的数据与Solr中写入的数据完全一致。 关键词：HBase, Solr, 分布式, 事务, 系统架构, 大数据 作者：王安琪（博客： http://www.cnblogs.com/wgp13x/ ） 一、关于分布式系统事务一致性问题 Java 中有三种可以的事务模型，分别称作本地事务模型（Local Transaction Model），编程式事务模型（Programmatic Transaction Model），和声明式事务模型（Declarative Transaction Model)。事务要求包含原子性（Atomicity），一致性（Consistency），独立性（Isolation），和持久性（Durability）。 《大型网站系统与Java中间件实践》一书中分享了一些解决分步式系统一致性问题的方案构思与实践，如在第六章中谈到的消息中间件。下表展现了解决一致性方案与传统方式的对比。 传统方式是，我做完了，发你消息。解决一致性的方案的意思就是，我先发你消息，我做完了再跟你确认我做完了。这是改进后的有事务的消息中间件。 因为在非XA 环境中，消息队列的插入过程独立于数据库更新操作

单机MySQL的美好时代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多 初期架构 | center DAL，（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1、数据量的总大小 一个机器放不下时。（表要占空间，表的索引要占空间） 2、数据的索引（B+ Tree树）一个机器的内存放不下时库 3、访问量(读写混合)一个实例不能承受，（读写一个库） 真正意义上的库应该是主从复制，读写分离，而mysql等数据库只能自己从自己的库中读与写，也就是自己和自己玩。 如果满足了上述1 or 3个，则需要进化.. Memcached(缓存,java上还有一个ehcache)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力， 优化数据库的结构和索引 。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享

提起分布式系统，就会涉及分布式事务，本文就以金融项目的转账业务为例，分析各种业务场景下的转账业务的事物问题。 一、业务场景 以工商银行转账业务为例，那么项目的分布式架构大致如下，一个银行的一个支行部署一个节点，那么相同节点之间的业务就是本地事务、不同节点之间的就是分布式事务 转账业务包括以下三种情况 支行内转账：同为工行的相同支行内转账（本地事务） 行内转账：同为工行的非同支行内转账 （分布式事务） 跨行转账：和其他银行的系统进行转账 （分布式事务） 1.1、支行内转账业务 如用户A和用户B都是工行-杭州支行的用户，A向B转账10000元，那么就需要保证事务，从而达到A的账户-10000，而B的账户+10000的效果 由于是本地事务，所以A账户的扣减和B账户的增加就可以放在一个事务中实现，基本上没有太大的问题，不管哪一步异常了都可以实现事务回滚。 1.2、行内转账 如用户A是杭州支行，用户B是北京支行，A向B转账10000元，那么虽然都是工行用户，但是是分布式部署的，就会涉及到跨库的分布式事务问题，一般解决方案有同步和异步两种方式： 同步方式可以如下： 1、创建转账订单，订单状态为待成功 2、用户A扣减10000元 3、发起转账请求到北京支行 4、北京支行创建转账订单，订单状态为待成功 5、用户B增加10000元 6、北京支行订单状态改为成功并返回结果 7、杭州支行接收响应结果

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付 又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。 有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。 C：一致性(Consistency)，事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。 如果事务成功地完成，那么系统中所有变化将正确地应用

微服务系统 事务 事务的原则 事务：是一种可靠，一致的方式，访问和操作数据库中数据的程序单元 原则特性： 原子性， 一致性 ，隔离性：事务之间互不干扰，持久性： 没提交事务之前，系统挂了，数据还是之前的数据，并没有被改变 mysql 查询事务的隔离级别 SELECT @@GLOBAL.tx_isolation,@@tx_isolation; 默认是 REPEATABLE-READ 可重复读 什么是 可重复读？ 比如 开启一个 事务，这个事务只读某一个表的 某条 的取数据。 但是这时候并没有提交 ， 但是 这时候另一个事务 修改了 该条数据，并提交了事务。 此时 之前的 的那个为 提交的事务，再次查询数据，这时候的数据是 未改变之前的数据，并不会因为 其他事务修改了数据提交了事务， 而显示出来 修改的值。 mysql 可重复读 修复 因为mysql 的事务隔离级别是 可重复读，另一个事务a 在执行更新数据，但是未提交， 这时候 一个事务 读取到 值之后， 另一个事务a更新了数据， 那么这时候 之前读取的值就不对了，怎么解决呢？ 1， 要么改 数据隔离级别是 序列化的, 可以修改当前 连接 session的 事务隔离级别 2. 使用 FOR UPDATE 这时候 比如 SELECT * FROM T_USER FOR UPDATE 此时 如果该表有未 提交事务，将等待 事务提交完成

一、Zookeeper简介 Zookeeper 是一个开源的分布式协调服务，目前由 Apache 进行维护。Zookeeper 可以用于实现分布式系统中常见的发布/订阅、负载均衡、命令服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。它具有以下特性： 顺序一致性 ：从一个客户端发起的事务请求，最终都会严格按照其发起顺序被应用到 Zookeeper 中； 原子性 ：所有事务请求的处理结果在整个集群中所有机器上都是一致的；不存在部分机器应用了该事务，而另一部分没有应用的情况； 单一视图 ：所有客户端看到的服务端数据模型都是一致的； 可靠性 ：一旦服务端成功应用了一个事务，则其引起的改变会一直保留，直到被另外一个事务所更改； 实时性 ：一旦一个事务被成功应用后，Zookeeper 可以保证客户端立即可以读取到这个事务变更后的最新状态的数据。 二、Zookeeper设计目标 Zookeeper 致力于为那些高吞吐的大型分布式系统提供一个高性能、高可用、且具有严格顺序访问控制能力的分布式协调服务。它具有以下四个目标： 2.1 目标一：简单的数据模型 Zookeeper 通过树形结构来存储数据，它由一系列被称为 ZNode 的数据节点组成，类似于常见的文件系统。不过和常见的文件系统不同，Zookeeper 将数据全量存储在内存中，以此来实现高吞吐，减少访问延迟。