我们思考这样一个问题，在互联网应用中，如果一张数据库的表中有1千万的数据量，某次需求调整，需要修改字段类型或者修改字段长度，或者 int 类型达到上限，你会怎么做？直接使用 `ALTER TABLE` 吗？

![image.png](https://blog.liushigong.cn/static/img/53a94247dfc782c4e07ed9bfd50e2e4c.image.webp)

## `ALTER TABLE` 问题分析

首先我们来分析一下，这个问题的本质就是对 mysql DDL 操作，虽然 MySQL 8.0.12 版本引入 `Instant DDL`（Instant Data Definition Language）允许在不阻塞读写（Online）的情况下，以毫秒级的速度修改表结构，当时在某些时候，还是会退回到最保守的 COPY 算法，例如：

* 修改数据类型
* 修改长度 (跨临界点，例如 varchar(255) 改成varchar(256))
* 修改字符集

COPY 算法

COPY 算法就是“复制数据”的过程。

当你要修改表结构时，MySQL 会生成一个临时表，把原表的数据一行行读出来，经过处理后再写入临时表，最后用临时表替换原表。

在使用 COPY 算法时，MySQL 在数据复制阶段，会给原表加上排他锁（Exclusive Metadata Lock）。这意味着在 DDL 执行期间，任何对原表的 `INSERT、UPDATE、DELETE` 操作都会被阻塞，直到 DDL 完成。

通过上面的分析，我们可以发现对于千万级的大表，直接使用 `ALTER TABLE` 会导致锁表，这个过程可能持续很长一段时间，这期间业务写入会堆积，连接池耗尽，最终导致整个服务不可用。

结合具体的场景来分析，如果是面向企业级的 TOB 系统，晚上系统是处于无人操作下，直接使用 `ALTER TABLE` 也不能说错。但是对于互联网的 TOC 应用是随时能访问的，对于高可用非常关注，所以我们需要另外的方案，这也是接下来我们的主题，数据迁移。

## 数据迁移

数据迁移是指把一批数据从一个数据库表迁移到另一个数据库表中。数据迁移的使用场景无非就是以下几种：

* 对某张表进行分库分表
* 数据库表中导致锁表的 DDL 操作
* 历史数据归档
* 需求调整产生的技术架构改变

当然数据迁移的前提是要以 **迁移的数据体量** 做考量的，不同的业务场景与不同的数据量，迁移的方案肯定是不一样的。如果只是几十万，都不需要搞那么复杂，直接导入导出 或者 写代码同步过来再做一下数据核对都能搞得定。

接下来我就以千万级数据量的大表为例，讲解下在业务无感知的情况下进如何行 **平滑迁移**。

### 迁移的数据类型

对于数据迁移的场景来说，主要包含两种数据的迁移类型，一个是开始迁移时的已存在数据的数据快照，也就是 **存量数据**，一个是程序运行时产生的新的数据，这部分数据就是 **增量数据**。

![image.png](https://blog.liushigong.cn/static/img/35f564f19beb0fe90773b3bf7f570c46.image.webp)

也就是我们在正式的数据迁移开始之前，需要定义个节点，作为存量数据的一致性数据快照，而在这个节点以后产生的 `insert` 数据，都是增量数据。在此处需要考虑一点，如果是 `update` 和 `delete` 操作的数据，不一定是存量也不一定是增量，要看他 `insert` 的时候是增量还是存量。

### 如何保障数据完整性的思考

在做数据迁移的时候，需要思考如何保障数据的完整性与一致性，怎么做到在不停机的情况下，将数据完整的迁移完成，例如上面描述的 `update` 和 `delete` 场景，都是需要去解决的问题。

其实最核心的解决处理就是在数据的读写上，那么我们就从 **读** 和 **写** 两步操作分析，首先是 **写** 处理：

* **数据实时性**：在开始平滑迁移后，需要保证旧系统和新系统数据的实时同步，直至完全切换到新系统。
* **insert 数据验证**：在双写的同时，需要有验证机制，例如定时查询每天的数据增量进行对比
* **update/delete 数据验证**：需要区别是增量数据还是存量数据的操作，进行单写或者双写。
* **存量数据的完整性**：存量数据在迁移的过程中需要确保所有数据都能准确的迁移到新表中，不能丢失数据。
* **存量数据数据验证**：存量数据迁移完成后，也是需要对存量数据进行验证。

接下来我们来分析下 **读** 操作的处理：

* **全量验证**：当写操作全部完成以后，我们再一次进行全量的验证，防止存量数据先读取在写入时，在并发下读取数据后数据产生了变更，导致最终的数据不一致的情况。
* **部分切流**：当全量数据么有问题以后，那么可以通过自定义开关控制，进行部分切流，如果有灰度环境可以在灰度上进行控制，在试验阶段，要保证尽可能的对业务影响最小
* **全量切流**：当部分切流验证没有问题后，就会进行全量切流，我们需要可以支持回滚，当一旦有问题，可以快速的做回滚。

![image.png](https://blog.liushigong.cn/static/img/fac0f24d2a7c37d230084533fdb4cb49.image.webp)

### 增量数据的迁移

首先我们来思考对于增量数据的迁移，处理的方案来说都是基于 **双写机制**，数据双写是指同时进行新表和老表的写入，让新表与老表中同时都有增量数据，这么做的主要原因一方面是让新数据不丢，另外也是随时可以做回滚。

![image.png](https://blog.liushigong.cn/static/img/b3c11ae0236355e6edebfbeff536a2f0.image.webp)

双写的方案有很多，主要有以下这么几种：

* **工具增量双写**：在增量双写过程中，我们可以用 `canal`、`flink cdc` 等这种增量数据更新的工具来进行双写，他们的原理就是在原库写入数据后，基于产生的binlog，自动把数据再写入新库。这个方案的好处是无需编码，支持各种异构的数据库，也支持表结构的各种不一致的转换。缺点就是依赖工具，需要单独部署，同时有可能存在失败或者延迟的风险，一旦过程中出问题了，中间的数据可能会丢失。
* **代码实现双写**：我们可以自己编码，在代码中实现双写，即写完旧库之后再写入新库。如果是同一个数据库的不同表的话，这里还可以借助事务保证数据的完整性。但是一般都是跨表或者跨库，所以这里需要考虑好重试的机制。优点就是代码实现的可靠性更强一些，逻辑可以自己定制，缺点就是需要写代码，比较复杂。
* **中间件异步双写**：其本质还是编码，但是我们不是直联数据库做写入，而是在写入新库的时候，通过 MQ 来做异步写入。

注意

编码方案中，在新表写入时，序列化ID 需要与旧表保持一致，而不是自增处理。

#### 增量数据更新

在数据迁移过程中，业务数据是会发生不断地变化的，前面的双写我们提了，只把新发生的 `insert` 当做增量。那这个过程中，如果发生了`update` 或者 `delete` 要怎么办呢？

其实这里就需要我们在编码的时候进行控制，在 `update/delete` 的时候，判断一下这个数据是增量的还是存量的，其实就是判断新表中是否有这个数据，如果有，就需要做双写更新，如果没有，就说明这是个存量数据，只更新旧表就行了。不用担心他们会丢，因为后续我们会做存量同步，这部分更新也会带过来的。

```
java

publiv viod update(){
    if(增量数据){
        同时更新旧表和新表();
    }else{
        更新旧表();    
    }
}
```

#### 增量数据核对

在数据迁移过程中，做数据核对是至关重要的。尤其是增量数据，因为增量数据需要双写，双写是有可能失败的，所以需要有一定的机制可以发现这些双写失败的数据。

在做数据核对方面，有很多方式，从编码上来说，像通过定时，单独服务批量查询数据，通过 MD5 加密进行对比；又或者加载到内存中转为字符串通过哈希code对比；建议去做旁路验证，流程是可以通过旁路（可以起一个异步线程，或者通过MQ等）进行一次新库的读取，然后把拿到的结果和旧库的读取作比对，当发现不一致的时候，报警报出来，进行人工核对。

还可以借助工具，把新表和旧表的数据做逐条核对，确保他们的数据是一模一样。

* mysqldiff：MySQL官方mysql-utilities工具集的一部分，用于对比不同数据库间的表结构或数据结构差异
* pt-table-checksum：Percona Toolkit核心工具，专为线上主从数据一致性高效校验设计，支持自动分块控制对业务影响
* Navicat：提供数据同步、结构比对等可视化核对功能
* GitHub check-data工具：支持双库数据CRC32校验及复核机制，可输出详细差异报告

### 存量数据的迁移

做好了增量数据迁移和核对之后，我们就可以把存量的数据也迁移过来了。存量数据的迁移也有很多方案，比如自己写代码去扫表迁移，也可以通过工具做存量的数据同步。

* **DataX**：是阿里云 DataWorks数据集成 的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。DataX 实现了包括 MySQL、Oracle、OceanBase、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、Hologres、DRDS, databend 等各种异构数据源之间高效的数据同步功能。
* **canal**：要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费
* **Kettle**：是一款开源的ETL（Extract, Transform, Load）工具，主要用于数据的抽取、转换和加载。通过Kettle，我们可以轻松地进行数据迁移，实现不同数据库之间的数据传输和整合。它允许你管理来自不同数据库的数据，通过提供一个图形化的用户环境来进行操作。
* **Flink CDC**（Change Data Capture，即数据变更抓取）是一个开源的数据库变更日志捕获和处理框架，它可以实时地从各种数据库（如MySQL、PostgreSQL、Oracle、MongoDB等）中捕获数据变更并将其转换为流式数据。Flink CDC 可以帮助实时应用程序实时地处理和分析这些流数据，从而实现数据同步、数据管道、实时分析和实时应用等功能。

对于存量的数据迁移，需要考虑几个问题：

1、**不能丢数据**：迁移过程中，数据的完整性需要保证，不能中间丢了数据  
2、**断点能续传**：迁移过程中，如果失败了，需要能够在失败处做断点续传，确保不重复不丢失。  
3、**不要覆盖增量数据**：存量数据在迁移的过程中，新表中是有增量数据的，所以，需要确保存量数据的迁移，不会覆盖到这部分已经存在的增量数据。  
4、**迁移性能要好**：存量数据一般都是量很大，所以迁移过程中的性能也是至关重要的。

为了保证数据不丢和能实现断点续传，我们可以在旧表中增加一个字段，来标识出这条记录是否已经被迁移过，这样我们就可以在一条记录迁移成功后，把他的这个标识改了，这样如果中间失败了，我们就知道哪些数据迁移过，哪些数据没迁移过，就只迁移这些没迁移的就行了。

有了这个标识之后，我们就可以做分批的迁移了，因为我们可以通过标记清晰的知道还有多少数据没迁移，可以方便的做分批处理和扫描。

为了不在存量数据迁移的过程中把增量数据覆盖了，这里就需要在 `insert` 之前做一个检查，判断下这个数据新表中是否已经存在了，已经存在的话，要么就是增量数据双写写进来的，要么就是上一次同步的时候失败了导致旧表的标记没来及更新，不管怎么样，直接认为这条记录已经迁移成功了就行。

提示

对于一些单表的操作，可以通过主键索引来保证唯一性，防止覆盖。

至于性能的问题，我们就需要通过各种手段来解决了，例如批处理，多线程、MQ等。

#### 存量数据核对

存量数据迁移完成以后，需要进行数据核对，与增量数据类似，就不过多描述了。

当增量与存量数据都完成以后，进行一次 **全量数据的验证**，主要防止增量数据期间产生的数据不一致的情况，验证完成后下一步就是要做读写切流了，要把读请求从老表切流到新表了，在这之前就需要确保是否可以切流。

## 数据切流

在确保数据都完成迁移之后，我们可以做切流了，一般是先把读请求切流到新的表上，跑一段时间，确保存量和增量数据都没问题，在切流写请求。

### 切流读新

在切流的时候，我们要逐步进行，比如根据可以基于用户ID的尾号，或者其他的业务字段来做切流，从10%，到20%，再到30%，50%，最后逐步放量到100%，最好有灰度的机制验证。

![image.png](https://blog.liushigong.cn/static/img/594ca72dd5866c6345f0124585cecbd8.image.webp)

这一步在切流之后，我们的旁路的策略也需要跟着调整。因为切流后读新表了，那么旁路就需要切换到读旧表。

### 切流写新

这是最后一步了，这一步也是唯一的一步不能回滚的步骤了，开始写切流。

![image.png](https://blog.liushigong.cn/static/img/06c0aa3badf5e74f0d0e3a8d5528be5b.image.webp)

这一步我们就要把双写去掉，完全变成单写了，这一步之后，旧表的数据就不会再做更新了。所以，在这一步之前，要做好足够的验证和核对，确保数据无误之后，在做谨慎操作。建议先切流1%，或者0.1%这样的比例切流。

### 开关&监控

在上述切流的这个过程中，我们就需要在代码中提前放好开关，然后在上线之后，只需要通过推开关就可以做控制流程的切换了。可以把这些开关配置到配置中心上，然后可以做到动态切换即可。

```
java

if(flag){
  // ...
  
}else{
  // ...
  
}
```

这里的 flag 就是个开关，这个值你可以通过配置中心进行动态的调整。

然后，除了核对以外，监控也至关重要，需要做好足够的监控来帮助我们提前的去发现问题。而且监控和核对是要覆盖了整个迁移流程的，一定不能裸奔！

比如在做旧表的读的时候，我们可以通过旁路（可以起一个异步线程，或者通过MQ等）进行一次新库的读取，然后把拿到的结果和旧库的读取作比对，当发现不一致的时候，报警报出来，进行人工核对。

到此我们整个平滑迁移就已经完成了。

数据库 - 千万数据如何做平滑的数据迁移?

数据库 - 深度探索 Mysql 的 binlog、redo log、undo log

生产中出现了 `org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only` 异常，结合源码分析下原因

## 示例

代码之间的调用如下

```
java

    @Transactional(rollbackFor = Exception.class)
    public void test() {
        // 测试出现 "Transaction rolled back because it has been marked as rollback-only"
        try {
            logService.testRockBack();
        } catch (Exception e) {
            System.out.println("try catch Exception : " + e.getMessage());
        }
    }
    
    
    @Override
    @Transactional(rollbackFor = Exception.class)
    public void testRockBack() {
        int i = 0;
        System.out.println(1/i);
    }
```

接口调用后，出现以下异常

![image.png](https://blog.liushigong.cn/static/img/b688dd2eba11571c5d581c5d7be0c98d.image.webp)

### 问题原因

在多个方法都有 `@Transactional`注解，A调用B，且把B的调用进行了try-catch

### 分析

从源码中开始分析，在 `AbstractPlatformTransactionManager #processRollback` 中，设置 `unexpectedRollback` 为 true 时，才会抛出此异常

![image.png](https://blog.liushigong.cn/static/img/1d55cdb2f359ca6c6da676fd221cf2d5.image.webp)

继续查看源码的调用栈，找到其 `processRollback(defStatus, true)` 方法处调用，入参为 true，那正常应该为不会调用到此方法，为什么此处会调用到呢？

我们接着分析下 `!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()` 这个判断条件

```
java

    /**
     * This implementation of commit handles participating in existing
     * transactions and programmatic rollback requests.
     * Delegates to {@code isRollbackOnly}, {@code doCommit}
     * and {@code rollback}.
     * @see org.springframework.transaction.TransactionStatus#isRollbackOnly()
     * @see #doCommit
     * @see #rollback
     */
    @Override
    public final void commit(TransactionStatus status) throws TransactionException {
        if (status.isCompleted()) {
            throw new IllegalTransactionStateException(
                            "Transaction is already completed - do not call commit or rollback more than once per transaction");
        }

        DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;
        if (defStatus.isLocalRollbackOnly()) {
            if (defStatus.isDebug()) {
                    logger.debug("Transactional code has requested rollback");
            }
            processRollback(defStatus, false);
            return;
        }

        if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
            if (defStatus.isDebug()) {
                    logger.debug("Global transaction is marked as rollback-only but transactional code requested commit");
            }
            processRollback(defStatus, true);
            return;
        }

        processCommit(defStatus);
    }
```

查看方法源码 `shouldCommitOnGlobalRollbackOnly()` 的实现底层，发现默认返回 false，那么此判断条件中一定为 true, 不会影响判断结果，核心的问题还是出现在 `defStatus.isGlobalRollbackOnly()` 的校验上，我们继续分析此方法

![image.png](https://blog.liushigong.cn/static/img/ab3bd73c9c220aa9a751c990563f068f.image.webp)

通过断点，可以确认此处判断调用到 `DataSourceTransactionManager #isRollbackOnly` 方法，其核心的 `rollbackOnly` 参数为 true，所以上述的逻辑判断中才会执行进程回滚的动作

![image.png](https://blog.liushigong.cn/static/img/83ad058e9d3abed168525012472725ca.image.webp)

![image.png](https://blog.liushigong.cn/static/img/ed2104f313fc0481ffe8bafc1dc39ff3.image.webp)

上述已然了解参数的定义，接下来查找下源码中如何设置成 true，从源码中发现如下代码设置为true

```
java

    /**
     * Mark the resource transaction as rollback-only.
     */
    public void setRollbackOnly() {
        this.rollbackOnly = true;
    }
```

查看代码的引用，发现一个熟悉的调用 `DataSourceTransactionManager #setRollbackOnly`

```
java

    public void setRollbackOnly() {
        getConnectionHolder().setRollbackOnly();
    }
```

![image.png](https://blog.liushigong.cn/static/img/f2944cb53c962c8811e475cf331973bf.image.webp)

从堆栈中查看调用信息，发现又回到了老朋友 `#processRollback` 方法上，

![image.png](https://blog.liushigong.cn/static/img/953f7915fa750dcc56443dcee5e8bc0a.image.webp)

此处有个判断 `status.hasTransaction()` 结果为 true，表示存在事务，在这做个事务源码的延伸，这部分为多个事务之间嵌套的处理，源码处理的位置如下

![image.png](https://blog.liushigong.cn/static/img/4cc1892cba6a84c9e747e836a2a154e6.image.webp)

继续查找堆栈信息，可以找到 `completeTransactionAfterThrowing` 方法

![image.png](https://blog.liushigong.cn/static/img/a9ee0e024c86a951cb4a32141dcec6c7.image.webp)

继续往上，就看到这是 `try catch` 部分，我们都知道事务底层实现就是aop，由于此问题出现的原因是嵌套事务，且嵌套中的事务抛出异常，当异常抛出后，就会被捕获，且将底层 `rollbackOnly` 设置为 true，此时接下来回归到到主线上调用 `commitTransactionAfterReturning` 方法进行提交

![image.png](https://blog.liushigong.cn/static/img/91f879acc6753b7502c5cecf5cdd60c5.image.webp)

其实走到这就很明朗了，此处代码已经是文章开头追溯的那部分源码

![image.png](https://blog.liushigong.cn/static/img/84287a5c3302beb547f42acf57164410.image.webp)

## 总结

梳理下源码的流程，当嵌套内事务抛出异常时，会将**全局仅回滚标记** `rollbackOnly = true` 设置为 true, 从源码的正常流程来说会把异常继续 throw，但是当我们外层事务 `try catch` 后，就导致异常无法抛出，最外层事务在执行后续 `commit` 时，会校验是否为**全局回滚参数**，抛出 `throw new UnexpectedRollbackException("Transaction rolled back because it has been marked as rollback-only")`;

![image.png](https://blog.liushigong.cn/static/img/5f37493125d6c6c73ecf6f57406591ea.image.webp)

Spring 多重事务嵌套产生的异常

在开发的过程中，使用事务与锁是解决一些问题最常用的方式，但是当这俩个结合起来你真的会用吗？在高并发的场景下会出现哪些问题？要如何避免这些问题？接下来，带你了解事务与锁之间真正的打开方式。

开发过程中，扣减库存是最经典的场景之一，接下来以此场景模拟扣减库存的代码实现

## 场景模拟

```
java

// 实体
@Data
public class MaterialStock {

    /**
     * 物料库存id
     */
    private Long id;

    /**
     * 物料名称
     */
    private String name;

    /**
     * 库存数量
     */
    private Long stockNum;
}
```

```
java

// 加锁 - 此处等同于分布式锁
ReentrantLock lock = new ReentrantLock();

// 实现方法
@SneakyThrows
@Override
@Transactional
public void updateById(Long id) {
    lock.lock();

    try {
        // 查询物料库存，扣减，然后更新库存
        MaterialStock materialStock = materialStockMapper.selectById(id);
        Long stockNum = materialStock.getStockNum();
        if (materialStock.getStockNum() <= 0) {
            log.info("库存不足");
            return;
        }
        materialStock.setStockNum(stockNum - 1);
        materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
        log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());

        // 其他处理，耗时 500ms
        TimeUnit.MILLISECONDS.sleep(500);
    }finally {
        // 释放锁
        lock.unlock();
    }
}
```

```
java

// 单元测试
public void test3(){
    for (int i = 0; i < 30; i++) {
        new Thread(() -> customExecutorService.updateById(1L)).start();
    }
}
```

接下来，模仿并发下的场景，设置20个库存，使用30个线程同步进行扣减，查看库存扣减的情况

![image.png](https://blog.liushigong.cn/static/img/17122a07c22211fffc8c8442411cd22e.image.webp)

可以发现，库存中出现了少扣的情况，按照我们预想的执行，流程上应该是【加锁 -> 查询库存 -> 扣减库存 -> 更新库存 -> 释放锁】，数据上【线程数 30 - 库存数 20 = 剩余库存数 10】

现在看来，锁应该是失效了，那这是怎么回事呢？

## 代码分析

首先分析，一定是在【查询库存】的环节异常，将上次扣减的库存查询出来，那出现这种情况只有两种可能性，一种是【加锁】环节没有生效，一种就是【更新库存】没有执行成功，目前代码上加锁逻辑没有任何问题，那么出现问题的就只能是【更新库存】了，通过对更新库存的操作进行断点，我们查看库存的扣减情况，下面过程中发现当【更新库存 -> 释放锁】的步骤执行完，数据库中的数据并没有更新，事务并没有提交。

![image.png](https://blog.liushigong.cn/static/img/1f685f9722aeb005f2fad4621fd17c4e.image.webp)

上面场景中，上一次线程库存数量已更新为18个，但是当前线程读取到的还是19个，且对此库存进行扣减，初步分析为上一个事务没有提交，当前线程就已经读取库存了。

说到这，了解事务实现原理的童鞋可能已经分析出来了，**事务底层是通过aop实现，aop底层又是动态代理对象实现，此时上一个线程update方法执行结束，锁已经释放了，但是整个service方法还没有执行结束，后置处理中的事务还没有提交，其他线程此时开始加锁读取库存数量，就导致了此问题的产生**。

## 解决方式

解决方式就比较多了，根据不同业务复杂度，可做不同的处理

1、业务场景简单的情况，将锁直接提到上层，调用带事务的service即可

```
java

    public void test3(){
        // 加锁
        ReentrantLock lock = new ReentrantLock();
        for (int i = 0; i < 30; i++) {
            new Thread(() -> {
                lock.lock();
                try {
                    customExecutorService.updateById(1L);
                }finally {
                    // 释放锁
                    lock.unlock();
                }
            }).start();
        }
    }
```

查看数据，发现正常扣减了

![image.png](https://blog.liushigong.cn/static/img/9962b4027812cdc7f34665cb0fb657cc.image.webp)

2、业务场景复杂的情况，要考虑锁的力度，根据业务逻辑拆分接口，可将逻辑校验都提到代码最前方，将库存校验留到校验的最后，且与更新库存进行绑定，进行加锁处理，流程如下

```
java

    // 加锁 - 此处等同于分布式锁
    ReentrantLock lock = new ReentrantLock();
    
    @Override
    public void updateById(Long id) {
        try {
            // 其他逻辑处理...
            
            lock.lock();
            // 处理事务
            stockNum(id);
        }finally {
            // 释放锁
            lock.unlock();
        }
    }

    @SneakyThrows
    @Transactional
    void stockNum(Long id) {
        // 查询物料库存，扣减，然后更新库存
        MaterialStock materialStock = materialStockMapper.selectById(id);
        Long stockNum = materialStock.getStockNum();
        if (materialStock.getStockNum() <= 0) {
            log.info("库存不足");
            return;
        }
        materialStock.setStockNum(stockNum - 1);
        materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
        log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());

        // 其他IO处理，耗时 500ms
        TimeUnit.MILLISECONDS.sleep(500);
    }
```

## 总结

解决这个问题的本质，**就是不要将锁，放到被事务方法中**，同时也要思考如果是其他aop切面或者自定义代理了方法会不会有影响。

往往开发的过程中使用的技术体系与底层的实现原理息息相关，掌握原理带动大脑思考

基于 Spring 声明式事务下锁失效的场景分析

很多小伙伴会问，为什么要准备面试前的自我复盘？这个问题很实际，自我的复盘有助于深入了解自身对职业发展，同时可以系统性地提升面试成功率。大多数人可能已经有一定面试经验，但通过复盘可以更结构化地准备，面试前的系统复盘是提升竞争力的关键。

## 面试前的复盘

作为高级开发者，往往需要的不是基础技术点的复习，而是深度和广度的平衡，以及项目经验的精准表达。大多数人潜在焦虑可能是：**如何在竞争中突出自己的优势**

### 对自身的复盘

首先要结合自身的定位进行一个复盘，需要系统性评估自己的市场竞争力和发展路径，一般会考虑以下几种情况：年龄、工作年限、薪资、技术体系、职业规划等等

其实复盘的本质就是 “如何在薪资期望、年龄压力、技术深度之间找到平衡点”，这比纯技术复盘更复杂，涉及市场定位和职业策略。对于大龄程序员换句话说，我该继续走技术专家路线，还是向架构师/管理转型？当前薪资要求是否合理？

#### 年龄与职业阶段对标（现实定位）

![deepseek_mermaid_20250605_28bcab.png](https://blog.liushigong.cn/static/img/44c76160a32f6273e1dd26b1b3a2350d.deepseek_mermaid_20250605_28bcab.webp)

复盘重点：

* 技术深度匹配度：35岁+需重点展示架构设计能力（如主导过百万级QPS系统）
* 管理潜力储备：准备技术管理双通道案例（如带队完成DevOps落地）
* 年龄优势转化：突出经验带来的风险预判能力（如规避过重大技术债务）

#### 工作年限价值挖掘（能力贴现）

| 年限 | 必备价值点 | 面试展现重点 |
| --- | --- | --- |
| 5-7年 | 复杂系统优化能力 | 性能提升量化指标（如GC耗时降80%） |
| 8-10年 | 技术决策ROI分析能力 | 技术选型对比报告（Kafka vs RocketMQ） |
| 10年+ | 技术战略规划能力 | 架构演进路线图（单体→微服务→云原生） |

这个时候在突出自己的亮点是需要额外的注意：

❌ “我做了XX年CRUD” → ✅ “近3年主导完成了支付系统架构升级，TPS从2k提升至12万”

#### 职业规划黄金三问（发展路径设计）

**技术深度规划**

例如：未来3年深耕云原生技术栈，计划考取CKA认证并落地Service Mesh，5年内具备百万级并发系统架构能力

**管理能力规划**

| 能力维度 | 当前水平 | 目标举措 |
| --- | --- | --- |
| 技术决策 | 模块级决策 | 学习TOGAF企业架构框架 |
| 团队培养 | 指导3人小组 | 建立新人培养SOP机制 |

**行业影响力规划**

* 技术输出：维护技术博客（年均20+原创）
* 社区参与：成为Apache项目Contributor
* 专利储备：申请2项分布式技术相关专利

### 掌握技术栈的复盘

对自身技术栈要有一个清晰的认知，可以罗列出主流技术栈，自我总结每项技术栈的掌握程度，对还没有掌握的知识体系进行学习补充。

**技术栈三维检测表**

重点准备「能说清原理但写不出代码」的技术点，例如：Spring循环依赖、Redis分布式锁、JVM FullGC优化等等

**源码级追问自测**

可以结合 `AI` 充当面试官，深入技术栈体系进行提问，做到能 **描述核心类结构**、**关键算法逻辑**、**指出源码缺陷/改进** 等程度

**硬伤转化策略（问题破局）**

| 潜在质疑点 | 转化策略 | 证据准备 |
| --- | --- | --- |
| 技术迭代能力 | 展示新技术落地案例 | 主导JDK17升级实践报告 |
| 薪资成本高 | 突出效能提升ROI | 自动化测试节省人天数据 |
| 职业激情衰退 | 开源项目贡献证明 | GitHub年度Contributor统计 |

### 项目经验的复盘

工作除了赚钱以后，并不是没有意义的，我们的复盘就是需要对工作中的 **价值提炼**

将工作中遇到的难点、生产问题与技术方案选型与实现进行总结与分析，将别人的知识转换成自己的，结合简历上项目的经验进行优化，尤其是 **量化指标** 的描述

**项目复盘STAR-R升级模型**

| 维度 | 关键问题 | 复盘重点 |
| --- | --- | --- |
| Situation | 项目背景中哪些是面试官关心的痛点？ | 用行业术语重构背景描述 |
| Task | 你的职责是否体现技术深度？ | 将"参与"改为"主导/设计" |
| Action | 技术方案是否有理论支撑？ | 关联CAP定理等原理 |
| Result | 数据是否量化到业务价值？ | "TPS↑200%" → "GMV↑5%" |
| Review | 如果重做会如何改进？ | 引入新技术方案对比 |

#### 案例转化

**原描述：**

“用Redis做了缓存优化”

**升级后：**

“针对商品查询接口99线>1s问题（痛点），主导设计多级缓存架构（LazyCache+Redis）（深度），
基于布隆过滤器解决缓存穿透（原理），查询性能提升15倍（量化），节省40%数据库成本（业务价值）”

### 总结

* 技术复盘：避免陷入“面经题海”，每天深挖1个核心原理比刷20题更重要
* 项目复盘：忌用“我们”模糊个人贡献，用“我设计/我推动/我实施”强化主动性
* 沟通陷阱：当被问“还有什么问题？”时，禁用“没问题”，可问：

  ```
  “团队在技术债管理上的实践？”
    “这个岗位解决的最核心技术挑战是什么？”
  ```

最后黄金法则：所有技术陈述遵循「三线穿透」原则：业务场景→技术实现→底层原理，

通过系统化复盘，将零散经验转化为结构化认知体系，面试官感知到的不仅是技术能力，更是清晰的思维框架和成长潜力。