事务管理

一、引用类型 1、强引用（Strong Reference） 一般用到最多的是强引用 2、软引用（Soft Reference） 如果一个对象没有强引用，只有软引用，当JVM发现内存不够时，垃圾回收器便会回收这些对象 3、弱引用（Weak Reference） 如果一个对象只有弱引用时，每次垃圾回收都会被回收 4、幻影引用（Phantom Reference） 如果一个对象仅持有幻影引用，那么它就和没有引用指向它一样，在任何时候该对象都可能被垃圾回收器回收。 幻影引用与软引用和弱引用的区别在于幻影引用必须和引用队列ReferenceQueue一起使用，幻影引用可以用来跟踪对象被回收的活动，因为当垃圾回收器准备回收一个对象的时候，如果发现它还有幻影引用，就会在回收之前，把这个幻影引用加入到与之关联的引用队列中去。 这样，程序通过判断引用队列中是否已经加入了幻影引用，来了解被引用对象是否将要被垃圾回收器回收，如果发现某个幻影引用已经被加入到引用队列，那么就可以在引用对象被回收之前采取必要的行动。 二、ThreadLocal 1、简介 ThreadLocal使用了弱引用，在一定程度上可以防止内存泄露。 2、ThreadLocal.ThreadLocalMap 此map使用的key是经过WeakReference包装的ThreadLocal对象

天天用事务，但是你知道MySQL事务的实现原理吗？ 1. 开篇 相信大家都用过事务以及了解他的特点，如原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)等。今天想跟大家一起研究下事务内部到底是怎么实现的，在讲解前我想先抛出个问题： 事务想要做到什么效果？ 按我理解，无非是要做到可靠性以及并发处理。 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 下面我首先讲实现事务功能的三个技术，分别是日志文件(redo log 和 undo log)，锁技术以及MVCC，然后再讲事务的实现原理，包括原子性是怎么实现的，隔离型是怎么实现的等等。最后在做一个总结，希望大家能够耐心看完 redo log与undo log介绍 mysql锁技术以及MVCC基础 事务的实现原理 总结 2 redo log 与 undo log介绍 1. redo

写在前面的话 本文所有Kafka原理性的描述除特殊说明外均基于Kafka 1.0.0版本。 为什么要提供事务机制 Kafka事务机制的实现主要是为了支持 Exactly Once 即正好一次语义 操作的原子性 有状态操作的可恢复性 Exactly Once 《 Kafka背景及架构介绍 》一文中有说明Kafka在0.11.0.0之前的版本中只支持 At Least Once 和 At Most Once 语义，尚不支持 Exactly Once 语义。 但是在很多要求严格的场景下，如使用Kafka处理交易数据， Exactly Once 语义是必须的。我们可以通过让下游系统具有幂等性来配合Kafka的 At Least Once 语义来间接实现 Exactly Once 。但是： 该方案要求下游系统支持幂等操作，限制了Kafka的适用场景 实现门槛相对较高，需要用户对Kafka的工作机制非常了解 对于Kafka Stream而言，Kafka本身即是自己的下游系统，但Kafka在0.11.0.0版本之前不具有幂等发送能力 因此，Kafka本身对 Exactly Once 语义的支持就非常必要。 操作原子性 操作的原子性是指，多个操作要么全部成功要么全部失败，不存在部分成功部分失败的可能。 实现原子性操作的意义在于： 操作结果更可控，有助于提升数据一致性 便于故障恢复。因为操作是原子的

影响mysql性能的几个方面： 1. 服务器硬件 2. 服务器操作系统 3. 数据库存储引擎 4. 数据库参数配置 5. 数据库结构设计和SQL语句 服务器硬件： 1. CPU： CPU密集型的应用，应选用频率更高的CPU而不是更多的CPU WEB类的应用，CPU核心数量比频率重要 2. 内存： 内存越多越好，内存对读、写都有作用 内存频率越高速度越快，应选择主板支持的最大内存频率，单条容量尽可能大 3. 磁盘： 传统机器硬盘：1.存储容量 2.传输速度 3.访问时间 4.主轴转速 5.物理尺寸 RAID（磁盘冗余阵列）： 1.RAID 0，2块以上的硬盘组成，没有冗余和错误修复能力 2.RAID 1，磁盘镜像，2块硬盘组成，有冗余 3.RAID 5，分布式奇偶性校验阵列，3块以上的硬盘组成，任意一个盘数据失效时可以重建，更多盘数据失效时无法重建 4.RAID 10，分片镜像，RAID 0和RAID 1组合，4块以上的硬盘组成，对比RAID 5重建更简单，速度更快 固态存储SSD或PCI-E卡： 比机械硬盘有更好的随机读写性能 比机械硬盘能更好的支持并发 比机械硬盘更容易损坏 适用于存在大量随机I/O的场景 适用于解决单线程负载的I/O瓶颈 网络存储SAN和NAS： SAN的随机读写慢，不如本地RAID磁盘 NAS设备使用网络连接，通过基于文件的协议如NFS或SMB来访问

原文: 高性能MySQL之事务 背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性；如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？因此简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现

1 MyISAM和InnoDB的区别 　　 a 是否支持行级锁 : 　　MyISAM 只有表级锁 (table-level locking)， 　　而 InnoDB 支持行级锁 (row-level locking)和表级锁,默认为行级锁。 　　 b 是否支持事务和崩溃后的安全恢复： 　　 MyISAM 强调的是性能 ，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。 　　但是 InnoDB 提供事务支持事务 ，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 　　 c 是否支持外键： 　　MyISAM不支持，而InnoDB支持。 　　 d 是否支持MVCC ： 　　仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。 2 索引 　　MySQL索引使用的数据结构主要有 BTree索引 和 哈希索 引 。 　　对于 哈希索引 来说

MongoDB 4.0 引入的事务功能，支持多文档ACID特性，例如使用 mongo shell 进行事务操作 > s = db.getMongo().startSession() session { "id" : UUID("3bf55e90-5e88-44aa-a59e-a30f777f1d89") } > s.startTransaction() > session.getDatabase("mytest").coll01.insert({x: 1, y: 1}) WriteResult({ "nInserted" : 1 }) > session.getDatabase("mytest").coll02.insert({x: 1, y: 1}) WriteResult({ "nInserted" : 1 }) > s.commitTransaction() （或者 s.abortTransaction()回滚事务） 支持 MongoDB 4.0 的其他语言 Driver 也封装了事务相关接口，用户需要创建一个 Session ，然后在 Session 上开启事务，提交事务。例如java版本 try (ClientSession clientSession = client.startSession()) { clientSession.startTransaction();

Spring 中集成 JOTM 配置 JTA 事务： 假如业务中要用到多个数据库，我们希望在业务方法中，当对某一个数据库的数据表进行操作的事务失败并回退（rollback），另外某一个数据库的数据表的操作事务也要回退，但应用一般的事务管理达不到这样的事务管理效果，这就需要实现 JTA 事务管理了。 这里我们在SPring中集成 Object web 的一个开源JTA实现JOTM (可以在 http://jotm.objectweb.org 下载完整版) 来实现JTA事务管理。 1、将必须的类包放入类路径中： jotm.jar, xapool.jar, jotm_jrmp_stubs.jar, jta-spect1_0_1.jar, connector-1_5.jar等等。 2、编写JOTM配置文件carol.properties，将其放到类路径下： Java代码 #JNDI调用协议 carol.protocols=jrmp #不使用CAROL JNDI封装器 carol.start.jndi= false #不启动命名服务器 carol.start.ns= false #JNDI调用协议 carol.protocols=jrmp #不使用CAROL JNDI封装器 carol.start.jndi=false #不启动命名服务器 carol.start.ns=false 3

一、分布式事务前奏 事务：事务是由一组操作构成的可靠的独立的工作单元，事务具备ACID的特性，即原子性、一致性、隔离性和持久性。 本地事务：当事务由资源管理器本地管理时被称作本地事务。本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 TX协议：应用或者应用服务器与事务管理器的接口。 XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁。之所以需要XA是因为在分布式系统中从理论上讲两台机器是无法达到一致性状态的，因此引入一个单点进行协调。由全局事务管理器管理和协调的事务可以跨越多个资源和进程。全局事务管理器一般使用XA二阶段协议与数据库进行交互。 AP：应用程序，可以理解为使用DTP（Data Tools Platform）的程序。 RM：资源管理器，这里可以是一个DBMS或者消息服务器管理系统

标签式配置，主要是标明回滚方法，超时，是否只读，以及隔离级别（不同session间事物的可见性，读取未提交，读取已提交，可重复读，序列化）及传播属性（定义了调用关系的事物传播行为 PROPAGATION_REQUIRED 支持当前事务，如果不存在 就新建一个(默认)；PROPAGATION_SUPPORTS 支持当前事务，如果不存在，就不使用事务；PROPAGATION_MANDATORY 支持当前事务，如果不存在，抛出异常；PROPAGATION_REQUIRES_NEW 如果有事务存在，挂起当前事务，创建一个新的事务；PROPAGATION_NOT_SUPPORTED 以非事务方式运行，如果有事务存在，挂起当前事务；PROPAGATION_NEVER 以非事务方式运行，如果有事务存在，抛出异常；PROPAGATION_NESTED 如果当前事务存在，则嵌套事务执行） 具体实现 TransactionAspectSupport，基本原理就是读各种配置，加载对应的事物管理器，根据事物标签，处理各种传递、可见性、执行、回滚、异常等情况；事物间传递用TransactionInfo对象保留现场 protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final