mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
Merge pull request #1698 from WT-AHA/main
[修改]：修改 MySQL事务隔离级别详解 关于幻读的案例演示和解决方案
This commit is contained in:
Guide
GitHub
commit
47f32f3f35
@ -127,11 +127,14 @@ SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTE
|
||||
<div align="center">
|
||||
<img src="https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-33-2可重复读.jpg"/>
|
||||
</div>
|
||||
|
||||
#### 幻读
|
||||
|
||||
##### 演示幻读出现的情况
|
||||
|
||||
|
||||
<div align="center">
|
||||
<img src="http://101.43.132.98:98/images/phantom_read.png"/>
|
||||
</div>
|
||||
|
||||
sql 脚本1 在第一次查询工资为 500 的记录时只有一条，sql 脚本 2 插入了一条工资为 500 的记录，提交之后；sql 脚本 1 在同一个事务中再次使用当前读查询发现出现了两条工资为 500 的记录这种就是幻读。
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ tag:
|
||||
- Spring
|
||||
---
|
||||
|
||||
JDK 中用到了那些设计模式?Spring 中用到了那些设计模式?这两个问题，在面试中比较常见。我在网上搜索了一下关于 Spring 中设计模式的讲解几乎都是千篇一律，而且大部分都年代久远。所以，花了几天时间自己总结了一下，由于我的个人能力有限，文中如有任何错误各位都可以指出。另外，文章篇幅有限，对于设计模式以及一些源码的解读我只是一笔带过，这篇文章的主要目的是回顾一下 Spring 中的设计模式。
|
||||
JDK 中用到了哪些设计模式?Spring 中用到了哪些设计模式?这两个问题，在面试中比较常见。我在网上搜索了一下关于 Spring 中设计模式的讲解几乎都是千篇一律，而且大部分都年代久远。所以，花了几天时间自己总结了一下，由于我的个人能力有限，文中如有任何错误各位都可以指出。另外，文章篇幅有限，对于设计模式以及一些源码的解读我只是一笔带过，这篇文章的主要目的是回顾一下 Spring 中的设计模式。
|
||||
|
||||
Design Patterns(设计模式) 表示面向对象软件开发中最好的计算机编程实践。 Spring 框架中广泛使用了不同类型的设计模式，下面我们来看看到底有哪些设计模式?
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ public class OrdersService {
|
||||
|
||||
这里再多提一下一个非常重要的知识点： **MySQL 怎么保证原子性的？**
|
||||
|
||||
我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行**回滚**，在 MySQL 中，恢复机制是通过 **回滚日志（undo log）** 实现的，所有事务进行的修改都会先先记录到这个回滚日志中，然后再执行相关的操作。如果执行过程中遇到异常的话，我们直接利用 **回滚日志** 中的信息将数据回滚到修改之前的样子即可！并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
|
||||
我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行**回滚**，在 MySQL 中，恢复机制是通过 **回滚日志（undo log）** 实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后再执行相关的操作。如果执行过程中遇到异常的话，我们直接利用 **回滚日志** 中的信息将数据回滚到修改之前的样子即可！并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
|
||||
|
||||
### Spring 支持两种方式的事务管理
|
||||
|
||||
@ -251,7 +251,7 @@ public interface TransactionDefinition {
|
||||
|
||||
`PlatformTransactionManager.getTransaction(…)`方法返回一个 `TransactionStatus` 对象。
|
||||
|
||||
**TransactionStatus 接口接口内容如下：**
|
||||
**TransactionStatus 接口内容如下：**
|
||||
|
||||
```java
|
||||
public interface TransactionStatus{
|
||||
@ -265,7 +265,7 @@ public interface TransactionStatus{
|
||||
|
||||
### 事务属性详解
|
||||
|
||||
际业务开发中，大家一般都是使用 `@Transactional` 注解来开启事务，很多人并不清楚这个参数里面的参数是什么意思，有什么用。为了更好的在项目中使用事务管理，强烈推荐好好阅读一下下面的内容。
|
||||
实际业务开发中，大家一般都是使用 `@Transactional` 注解来开启事务，但很多人并不清楚这个注解里面的参数是什么意思，有什么用。为了更好的在项目中使用事务管理，强烈推荐好好阅读一下下面的内容。
|
||||
|
||||
#### 事务传播行为
|
||||
|
||||
@ -273,7 +273,7 @@ public interface TransactionStatus{
|
||||
|
||||
当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。
|
||||
|
||||
举个例子：我们在 A 类的`aMethod（）`方法中调用了 B 类的 `bMethod()` 方法。这个时候就涉及到业务层方法之间互相调用的事务问题。如果我们的 `bMethod()`如果发生异常需要回滚，如何配置事务传播行为才能让 `aMethod()`也跟着回滚呢？这个时候就需要事务传播行为的知识了，如果你不知道的话一定要好好看一下。
|
||||
举个例子：我们在 A 类的`aMethod()`方法中调用了 B 类的 `bMethod()` 方法。这个时候就涉及到业务层方法之间互相调用的事务问题。如果我们的 `bMethod()`如果发生异常需要回滚，如何配置事务传播行为才能让 `aMethod()`也跟着回滚呢？这个时候就需要事务传播行为的知识了，如果你不知道的话一定要好好看一下。
|
||||
|
||||
```java
|
||||
Class A {
|
||||
@ -308,7 +308,7 @@ public interface TransactionDefinition {
|
||||
}
|
||||
```
|
||||
|
||||
不过如此，为了方便使用，Spring 会相应地定义了一个枚举类：`Propagation`
|
||||
不过，为了方便使用，Spring 相应地定义了一个枚举类：`Propagation`
|
||||
|
||||
```java
|
||||
package org.springframework.transaction.annotation;
|
||||
@ -455,7 +455,7 @@ public interface TransactionDefinition {
|
||||
}
|
||||
```
|
||||
|
||||
和事务传播行为这块一样，为了方便使用，Spring 也相应地定义了一个枚举类：`Isolation`
|
||||
和事务传播行为那块一样，为了方便使用，Spring 也相应地定义了一个枚举类：`Isolation`
|
||||
|
||||
```java
|
||||
public enum Isolation {
|
||||
@ -506,9 +506,9 @@ mysql> SELECT @@tx_isolation;
|
||||
|
||||
~~这里需要注意的是：与 SQL 标准不同的地方在于 InnoDB 存储引擎在 **REPEATABLE-READ（可重读）** 事务隔离级别下使用的是 Next-Key Lock 锁算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说 InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）** 已经可以完全保证事务的隔离性要求，即达到了 SQL 标准的 **SERIALIZABLE(可串行化)** 隔离级别。~~
|
||||
|
||||
🐛 问题更正：**MySQL InnoDB 的 REPEATABLE-READ（可重读）并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁读使用到的机制就是 Next-Key Locks。**
|
||||
🐛 问题更正：**MySQL InnoDB 的 REPEATABLE-READ（可重读）并不保证避免幻读，需要使用加锁读来保证。而这个加锁读使用到的机制就是 Next-Key Locks。**
|
||||
|
||||
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEAaTABLE-READ（可重读）** 并不会有任何性能损失。
|
||||
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）** 并不会有任何性能损失。
|
||||
|
||||
InnoDB 存储引擎在 **分布式事务** 的情况下一般会用到 **SERIALIZABLE(可串行化)** 隔离级别。
|
||||
|
||||
@ -518,7 +518,7 @@ InnoDB 存储引擎在 **分布式事务** 的情况下一般会用到 **SERIALI
|
||||
|
||||
#### 事务超时属性
|
||||
|
||||
所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。在 `TransactionDefinition` 中以 int 的值来表示超时时间，其单位是秒，默认值为-1。
|
||||
所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。在 `TransactionDefinition` 中以 int 的值来表示超时时间，其单位是秒，默认值为-1，这表示事务的超时时间取决于底层事务系统或者没有超时时间。
|
||||
|
||||
#### 事务只读属性
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user