事务管理

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 数据库的连接器，连接器获取权限，维持管理连接；连接完成后如果你没有后续的指令这个连接就会处于空闲状态

Zookeeper是什么 ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Leader选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，会统一由Leader接收并处理，广播给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 分布式系统的CAP原则是什么？ZK实现的是AP还是CP？ CAP原则又称CAP定理

并发，在操作系统中，是指一个很短的时间段中有几个程序都处于已启动运行到运行完毕之间，并发程序之间有相互制约关系，直接制约体现为一个程序需要另一个程序的计算结果，间接制约体现为多个程序竞争同一资源，如处理机、缓冲区、数据等。在数据库系统中，并发主要是指资源的争用，当两个进程同时在访问或更新同一个数据时，产生资源的争用，资源争用会引起一系列的问题，比如数据不一致、查询阻塞、死锁等。 一，并发模式 在数据库系统中，当多个进程访问同一资源时，默认情况下，SQL Server会通过各种类型的锁来协调资源的访问，确保在并发环境下数据保持一致的状态。而锁的作用范围是在事务中，事务建立在并发模式下。并发模式控制当发生读写冲突时，数据应该如何处理以保证数据的一致性。注意，写和写之间永远冲突。 1，乐观并发模式 对于乐观并发模式，SQL Server假设只有少量的冲突发生，默认的机制是使用快照技术，在写进程完成修改数据之前，先把数据的行版本保存到tempdb中。由于数据的旧数据已经保存，读进程可以直接读取已经保存的行版本，而不会受到写进程的影响。 乐观并发使得读写进程不会相互阻塞，但是，这会导致一个潜在的问题，读进程可能会读取到老的数据。 2，悲观并发模式 这是默认的并发模式，在悲观并发模式下，SQL Server认为有大量的写操作发生，并且写操作会受到写操作的影响。也就是说

概述 事务管理对于企业应用来说是至关重要的，即使出现异常情况，它也可以保证数据的一致性。 Spring Framework对事务管理提供了一致的抽象，其特点如下： 为不同的事务API提供一致的编程模型，比如JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects) 支持声明式事务管理，特别是基于注解的声明式事务管理，简单易用 提供比其他事务API如JTA更简单的编程式事务管理API 与spring数据访问抽象的完美集成 事务管理方式 spring支持编程式事务管理和声明式事务管理两种方式。 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况 提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的 事务规则声明(或通过基于@Transactional注解的方式)

背景 数据库中有一张叫 后宫佳丽 的表,每天都有几百万新的小姐姐插到表中,光阴荏苒,夜以继日,日久生情,时间长了,表中就有了几十亿的 小姐姐 数据,看到几十亿的小姐姐,每到晚上,我可愁死了,这么多小姐姐,我翻张牌呢? 办法当然是精兵简政,删除那些 age>18 的,给年轻的小姐姐们留位置... 于是我在数据库中添加了一个定时执行的小程序,每到周日,就自动运行如下的脚本 delete from `后宫佳丽` where age>18 一开始还自我感觉良好,后面我就发现不对了,每到周日,这个脚本一执行就是一整天,运行的时间有点长是小事,重点是这大好周日,我再想读这张表的数据,怎么也读不出来了,怎是一句空虚了得,我好难啊! 为什么 编不下去了,真实背景是公司中遇到的一张有海量数据表,每次一旦执行历史数据的清理,我们的程序就因为读不到这张表的数据,疯狂地报错,后面一查了解到,原来是因为定时删除的语句设计不合理,导致数据库中数据由行锁( Row lock )升级为表锁( Table lock )了😂. 解决这个问题的过程中把数据库锁相关的学习了一下,这里把学习成果,分享给大家,希望对大家有所帮助. 我将讨论SQL Server锁机制以及如何使用SQL Server标准动态管理视图监视SQL Server 中的锁,相信其他数据的锁也大同小异,具有一定参考意义. 铺垫知识 在我开始解释SQL

MySQL默认存储引擎为InnoDB，可以通过使用命令SHOW VARIABLES LIKE 'storage_engine'; 一、InnoDB存储引擎 1.InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID） 　（MyISAM：不支持事务； 只支持表级锁 ) 事务的ACID属性：即原子性、一致性、隔离性、持久性 a.原子性：原子性也就是说这组语句要么全部执行，要么全部不执行，如果事务执行到一半出现错误，数据库就要回滚到事务开始执行的地方。 实现：主要是基于MySQ日志系统的redo和undo机制。事务是一组SQL语句，里面有选择，查询、删除等功能。每条语句执行会有一个节点。例如，删除语句执行后，在事务中有个记录保存下来，这个记录中储存了我们什么时候做了什么事。如果出错了，就会回滚到原来的位置，redo里面已经存储了我做过什么事了，然后逆向执行一遍就可以了。 b.一致性：事务开始前和结束后，数据库的完整性约束没有被破坏。（eg:比如A向B转账，不可能A扣了钱，B却没有收到） c.隔离性：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰； 如果不考虑隔离性则会出现几个问题： i、脏读：是指在一个事务处理过程里读取了另一个未提交的事务中的数据（当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据

1、什么是事务 事务是由一步或者几步数据库操作序列组成的逻辑执行单元，这系列操作要么全部执行，要么全部放弃执行。 2、事务具备的4个特性： 1》原子性（Atomicity）：事务是应用中最小的执行单位，事务是应用中不可再分的最小逻辑执行体。 2》一致性（Consistency）：事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。当数据库只包含事务成功提交的结果时，数据库处于一致性状态。如果系统运行发生中断，某个事务尚未完成而被迫中断，而该未完成的事务对数据库所做的修改已被写入数据库，此时数据库就处于一种不正确的状态。一致性是通过原子性来保证的。 3》隔离性（Isolation）：各个事务的执行互不干扰，任意一个事务的内部操作对其他并发的事务都是隔离的。 4》持续性（Durability）：持续性也称为持久性，指事务一旦提交，对数据所做的任何改变都要记录到永久存储器中，通常就是保存进物理数据库。 3、数据库的事务由下列语句组成： 1》一组DML语句，经过这组DML语句修改后的数据将保持较好的一致性。 2》一条DDL语句 3》一条DCL语句 DDL和DCL语句最多只能是一条，因为DDL和DCL语句都会导致事务立即提交。 4、当事务所包含的全部数据库操作都成功执行后，应该提交（commit）事务，使修改永久生效。事务提交的两种方式： 1》显式提交：使用commit 2

服务组成 transcations service service A service B service ... transcation service 负责管理事务性的操作，功能 创建 transcation，事务 struct ({ api_list: [{ status, put_api_from_service_A, get_api_from_service_A}, ...]}) 创建 job, 执行一次 transcation 的记录 struct (transaction_id, status, api_from_service_A_params, api_from_service_A_returned_data), status 有 (pending, successed, failure, cancelled) 其他的管理接口 other services 提供幂等的api，api 具有标识任务 success or failure 的返回 事务控制流程 在 transcation service 上定义一个 transaction 包含 service A 的 api service A 在 transcation service 创建一个 job，job status 为 pending transcation service 通过注册的 get api 获取

提起分布式系统，就会涉及分布式事务，本文就以金融项目的转账业务为例，分析各种业务场景下的转账业务的事物问题。 一、业务场景 以工商银行转账业务为例，那么项目的分布式架构大致如下，一个银行的一个支行部署一个节点，那么相同节点之间的业务就是本地事务、不同节点之间的就是分布式事务 转账业务包括以下三种情况 支行内转账：同为工行的相同支行内转账（本地事务） 行内转账：同为工行的非同支行内转账 （分布式事务） 跨行转账：和其他银行的系统进行转账 （分布式事务） 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)，事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。 如果事务成功地完成，那么系统中所有变化将正确地应用