Spring的7 种事务传播行为概要1.docx

Transaction 也就是所谓的事务了，通俗理解就是一件事情。从小，父母就教育我们，做事情要有始有终，不能半途而废。?事务也是这样，不能做一般就不做了，要么做完，要么就不做。也就是说，事务必须是一个不可分割的整体，就像我们在化学课里学到的原子，原子是构成物质的最小单位。于是，人们就归纳出事务的第一个特性：原子性（Atomicity）。我靠，一点都不神秘嘛。特别是在数据库领域，事务是一个非常重要的概念，除了原子性以外，它还有一个极其重要的特性，那就是：一致性（Consistency）。也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。如果出现了这类事情，您一定会非常气愤，什么 diao 银行啊！当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，可以想象，如果不稍加控制，就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的（线程之间有时也要做到隔离），彼此之间没有任何干扰。这就是：隔离性（Isolation）。要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”，这个规范就是：事务隔离级别（Transaction Isolation Level）。能定义出这样牛逼的规范真的挺不容易的，其实说白了就四个级别：READ_UNCOMMITTEDREAD_COMMITTEDREPEATABLE_READSERIALIZABLE千万不要去翻译，那只是一个代号而已。从上往下，级别越来越高，并发性越来越差，安全性越来越高，反之则反。当我们执行一条 insert 语句后，数据库必须要保证有一条数据永久地存放在磁盘中，这个也算事务的一条特性，?它就是：持久性（Durability）。归纳一下，以上一共提到了事务的 4 条特性，把它们的英文单词首字母合起来就是：ACID，这个就是传说中的“事务 ACID 特性”！真的是非常牛逼的特性啊！这 4 条特性，是事务管理的基石，一定要透彻理解。此外还要明确，这四个家伙当中，谁才是老大？其实想想也就清楚了：原子性是基础，隔离性是手段，持久性是目的，真正的老大就是一致性。数据不一致了，就相当于“江湖乱套了，流氓戴胸罩”。所以说，这三个小弟都是跟着“一致性”这个老大混，为他全心全意服务。这四个家伙当中，其实最难理解的反倒不是一致性，而是隔离性。因为它是保证一致性的重要手段，是工具，使用它不能有半点差池，否则后果自负！怪不得数据库行业专家们都要来研究所谓的事务隔离级别了。其实，定义这四个级别就是为了解决数据在高并发下所产生的问题，那又有哪些问题呢？Dirty Read（脏读）Unrepeatable Read（不可重复读）Phantom Read（幻读）首先看看“脏读”，看到“脏”这个字，我就想到了恶心、肮脏。数据怎么可能脏呢？其实也就是我们经常说的“垃圾数据”了。比如说，有两个事务，它们在并发执行（也就是竞争）。看看以下这个表格，您一定会明白我在说什么：时间事务 A（存款）事务 B（取款）T1开始事务T2开始事务T3查询余额（1000 元）T4取出 1000 元（余额 0 元）T5查询余额（0 元）T6撤销事务（余额恢复为 1000 元）T7存入 500 元（余额 500 元）T8提交事务余额应该为 1500 元才对！请看 T5 时间点，事务 A 此时查询余额为 0 元，这个数据就是脏数据，它是事务 B 造成的，明显事务没有进行隔离，渗过来了，乱套了。所以脏读这件事情是非常要不得的，一定要解决掉！让事务之间隔离起来才是硬道理。那第 2 条，不可重复读又怎么解释呢？还是用类似的例子来说明：时间事务 A（存款）事务 B（取款）T1开始事务T2开始事务T3查询余额（1000 元）T4查询余额（1000 元）T5取出 1000 元（余额 0 元）T6提交事务T7查询余额（0 元）事务 A 其实除了查询了两次以外，其他什么事情都没有做，结果钱就从 1000 变成 0 了，这就是重复读了。可想而知，这是别人干的，不是我干的。其实这样也是合理的，毕竟事务 B 提交了事务，数据库将结果进行了持久化，所以事务 A 再次读取自然就发生了变化。这种现象基本上是可以理解的，但在有些变态的场景下却是不允许的。毕竟这种现象也是事务之间没有隔离所造成的，但我们对于这种问题，似乎可以忽略。最后一条，幻读。我去！Phantom 这个单词不就是“幽灵、鬼魂”吗？刚看到这个单词时，真的把我的小弟弟都给惊呆了。怪不得这里要翻译成“幻读”了，总不能翻译成“幽