记一次模拟断电，事务回滚。

最新推荐文章于 2024-12-06 17:11:23 发布
最新推荐文章于 2024-12-06 17:11:23 发布
阅读量788 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 错误指南 文章标签： mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Alonetramp/article/details/105800560
本文探讨了在代码中断点后程序中断导致事务不回滚的问题，分析了事务不会回滚的常见原因，包括调用自身类方法和使用非InnoDB数据库。并通过模拟断电测试，验证事务的正常回滚机制。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在代码中部下断点后中断程序，事务是不会回滚的，这样会污染数据。暂时不理解事务不会回滚的原因。

模拟断电应该用线程休眠，然后直接中断程序，这样可以看到事务确实有正常回滚。

 

 

不会回滚的原因一般基本就是

1.调用了自身类方法这样是不会回滚的。这个很容易知道，毕竟AOP。

2.数据库不是inndb。

数据库故障排查指南，未提交的事务导致数据回滚
百态老人的博客
05-22 581
两阶段提交（2PC）协议是分布式事务处理的核心机制之一，尽管其设计简单且能保证事务的一致性，但在实际应用中仍面临性能瓶颈和可用性挑战。通过引入移动代理、超时机制、副本协议以及优化锁资源管理等策略，可以显著提升2PC协议的效率和可靠性。
mysql事务未提交断开连接,连接丢失/断开连接的事务的MySQL回滚
weixin_42372731的博客
01-20 697
I need to make MySQL server to rollback transaction immediately after its client disconnected, because each client works concurrently. The problem can be reproduced like these (using an innodb table t...
事务是如何回滚的
王鹏的专栏
08-19 2142
先举个栗子： 大家应该都用过office Word，之前一直盛传如果电脑突然断电了，文档会丢失，这个是很早的时候的问题了，现在已经解决了，我们看一下是如何解决的，当我们在编辑文档的时候，每隔一段时间，word会自动把当前的编辑记录记下来， 我们可以把每一次的开始编辑作为一次事务的 Begin，每一次的保存作为事务的 Commit，不保存退出作为事务的 Rollback。 之后如果正常保存后，就清除这些log，如果突然断电了，再次打开的时候软件发现有日志，就提示用户是rollback还是commit。 这
MySQL 事务提交一半断电，会怎么样？
cda2024的博客
12-06 992
在数据库管理中，事务是一组逻辑操作单元，这些操作要么全部成功执行，要么全部不执行。原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的操作要么全部完成，要么全部不完成。一致性（Consistency）：事务必须使数据库从一个一致性状态转换到另一个一致性状态。隔离性（Isolation）：事务的执行不受其他事务的干扰，每个事务都独立运行。持久性（Durability）：一旦事务提交，其对数据库的改变是永久性的，即使系统发生故障也不会丢失。
stop slave后，正在执行的事务是完成了还是回滚了rollback
翔云
08-15 387
目录1.关于stop slave后，事务执行结果2.观察事务回滚2.1.设置从库的事务隔离级别2.2.启动SQL thread2.3.停止复制，查看事务执行情况 1.关于stop slave后，事务执行结果 如果从库上SQL线程正在应用relay log，或者说正在执行一个事务，此时如果stop slave，那么这个事务执行结果会是什么，完成还是未完成？ 由于事务的原子性，可以这么说，事务要么执行完成，要么回滚。 先说结论，事务执行结果有两种： 执行完成 未执行完成（事务回滚） 那什么情况执行完成，什么
数据库的事务
qq_58000413的博客
10-04 548
所有事务中都是为了保证数据的一致性，所以一致性是最终的追求，事务中的一致性是通过原子性、隔离性、持久性来保证的。最终是为了保证数据的一致性，当经过N多次操作之后，数据的状态从一个一致性到另外一个一致性状态，也就是数据不可发生不一致。各个事务之间相关不会产生影响，严格的隔离性会呆滞效率降低，在某些情况下为了提高执行效率会降低隔离性的级别。这些操作要么都做，要么都不做，是一个不可分割的工作单位，是数据库环境中的逻辑单位。一般情况下，锁的粒度越小，效率越高，粒度越大，效率越低。3.用户关闭会话之后，会自动提交。
①①MySQL事务transaction（手动事务、事务操作、事务操作原理、回滚点、自动事务处理、事务的四大特性：ACID、锁机制 ）
SUNZHUANGZHUANG的博客
02-24 299
mysql.exe -h localhost -P 3306 -u root -p use mydb; —— 进入数据库 查看：show index from 表名\G desc：查看表结构 select * from 表名：查询所有数据 提交事务：commit; 同步数据表，表示操作成功 回滚事务：rollback; 直接清空日志表，表示操作失败 事务transaction 事务...
结束事务的其他情景
m0_46160024的博客
10-13 731
结束事务的其他情景
mysql 断电_mysql的断电恢复能力
weixin_30299319的博客
01-18 935
这段时间对mysql数据库事务的acid做了一些深入的研究，理解了如何在异常情况下保证事务的acid。而最严重的异常情况莫过于断电，随时都有可能发生且发生时不会有任何保存的机会，所以就想以事务处理的各个阶段发生断电的情况下mysql如何保证acid为切入点总结一下这段时间所学到的东西。概述这段时间对mysql数据库事务的acid做了一些深入的研究，理解了如何在异常情况下保证事务的acid。而最严重...
事务的回滚和不提交的区别
热门推荐
shaowei的专栏
07-14 1万+
当出现异常，事务没有提交，不回滚有影响吗？ 1. 在同一事务条件下,回滚和不提交,表现是一样的 但是还有些差别 事务处理,是将操作事件交给数据库(模拟)运行,直到commit操作,才使得修改实际产生效果,你可以看做是未提交事务都是处于一个临时库中进行 回滚是对于同一个事务,如果产生了错误,那么取消这个临时库中的操作,不对实际数据产生影响 最主要的区别在于,如果不
事务失败会全部回滚吗？
Owen_Zeng 的博客
01-30 6149
前言 这个问题看起来是一个简单明了，显而易见的问题。 事务应该是原子的，要么整个事务完成，要么没有完成。 举个栗子 CREATE TABLE TestingTransactionRollbacks ( ID INT NOT NULL PRIMARY KEY , SomeDate DATETIME DEFAULT GETDATE() ) ; GO BEGIN TRANSACTIO
模拟断电oracle数据不一致,Oracle数据库案例整理-Oracle系统运行时故障-断电导致数据文件状态变为RECOVER...
weixin_39674414的博客
04-05 148
1.1 现象描述异常断电，数据库数据文件的状态由ONLINE变为RECOVER。系统显示如下信息：SQL> select file_name ,tablespace_name ,online_status from dba_data_files;FILE_NAME-----------------------------------------------------------...
模拟断电oracle数据不一致,Oracle断电不一致_重建控制文件的恢复
weixin_33456452的博客
04-05 251
故障现象由于机房UPS没有完善，开发库服务器在没有正常关闭数据库的情况下断电关闭，当服务器开机后，数据库启动失败，在open阶段提示：/opt/app/oradata/orcl/system01.dbf不一致，需要介质恢复。故障处理背景由于该开发库只有逻辑备份，没有物理备份，并且逻辑备份只是备份了数据库结构，并没有真实的数据，虽然开发库数据不是很重要，但由于开发人员都在上面进行项目开发，包含了最新...
一个spring batch批处理步骤和quatz调度和断电续跑容错处理帮我设计一下
最新发布
03-14
<think>好的，我现在需要帮用户设计一个结合Spring Batch批处理步骤、Quartz调度以及断电续跑容错处理的方案。首先，我得回顾一下用户之前的问题，他之前询问过断点续跑的实现，现在希望整合调度和容错处理。 用户可能正在开发一个需要定期执行批处理任务的系统，比如每天处理数据，同时需要保证在任务执行过程中遇到断电或故障时能够恢复。Spring Batch负责批处理，Quartz用来调度任务，而断点续跑则是容错的关键。我需要确保这三部分能够协同工作。 首先，Spring Batch的JobRepository已经具备状态持久化的能力，可以记录每个步骤的执行情况，这样在重启时可以从断点继续。Quartz作为调度器，需要正确配置触发批处理作业的时间。关键在于如何将两者结合起来，并确保在任务中断后，Quartz再次触发时能够正确识别未完成的作业并恢复。 接下来，我需要考虑组件集成部分。可能需要配置Quartz的JobDetail来触发Spring Batch的JobLauncher，同时传递必要的参数。这里要注意作业参数的唯一性，避免重复执行，或者确保重启时使用相同的参数来定位之前的执行实例。 然后，容错处理方面，除了Spring Batch自带的断点续跑功能，还需要处理可能的异常，比如在任务执行期间断电。需要确保每个chunk的事务正确提交，这样在恢复时可以从最后一个提交点继续。此外，可能需要配置重试策略，比如网络故障时的重试机制。 另外，用户可能关心集群环境下的处理，因为Quartz在集群中需要数据库来同步状态，而Spring Batch的JobRepository也需要数据库支持。需要确保两者使用同一个数据库或者不同的数据源，避免冲突。同时，分布式锁机制可能需要在集群中防止多个节点同时执行同一个任务。 在设计步骤时，需要详细说明每个部分的配置，比如如何定义Spring Batch的Job和Step，如何配置Quartz的触发器和Job，以及如何启用重试和跳过机制。可能还需要考虑监控和日志，方便追踪任务执行状态和故障排查。 最后，注意事项部分需要提醒用户参数唯一性、事务边界、状态清理和集群协调等问题。这些都是实际应用中容易遇到的坑，提前说明可以帮助用户避免常见错误。 现在需要把这些思路整理成一个结构清晰的方案，确保用户能够按照步骤配置和实现，同时理解各部分的作用和协作方式。需要检查是否有遗漏的细节，比如Quartz和Spring Batch的版本兼容性，或者是否需要额外的依赖库。此外，是否需要示例配置或代码片段？不过用户之前要求纯文字描述，所以应该避免代码，用文字详细说明配置方法。 总结下来，设计方案需要分模块介绍，包括核心架构、组件集成、执行流程、容错策略和注意事项，每个部分都要详细但简洁，确保用户能够理解并实施。</think>--- ### **系统架构设计** #### **1. 核心组件关系图** ``` [Quartz Scheduler] └─ 定时触发 → [Spring Batch JobLauncher] → [批处理Job] ├─ [可重启Step]（含容错机制） ├─ [ItemReader(状态感知)] ├─ [ItemProcessor(重试逻辑)] └─ [ItemWriter(事务控制)] ↔ [JobRepository]（状态存储DB） ``` --- ### **分层实现方案** #### **一、Spring Batch批处理层** **1. 可恢复Job定义** ```properties # 配置示例（非代码，仅逻辑描述） Job定义： - 名称: dataMigrationJob - 包含步骤: chunkStep（分块处理） - 重启属性: restartable=true Step配置： - 读取器: JdbcCursorItemReader（支持游标定位） - 处理器: RetryableProcessor（带@Retryable注解） - 写入器: JdbcBatchItemWriter（批量提交） - 块大小: 100（每处理100条提交事务） - 跳过策略: 跳过DataIntegrityViolationException - 重试策略: 网络超时自动重试3次 ``` **2. 状态持久化配置** ```properties 关键配置项： - spring.batch.jdbc.initialize-schema: always（自动建表） - 使用独立数据源存储作业状态 - 启用ExecutionContext自动持久化 ``` --- #### **二、Quartz调度层** **1. 调度任务绑定** ```properties 触发器配置： - Cron表达式: 0 0 3 * * ?（每日凌晨3点执行） - 附带参数: executionId=#{new java.util.Date().getTime()}（保证参数唯一性） JobDetail配置： - 关联JobClass: QuartzJobLauncher（自定义桥接类） - 传递参数: jobName=dataMigrationJob - 持久化策略: durable（保留触发记录） ``` **2. 集群环境适配** ```properties 高可用配置： - org.quartz.jobStore.isClustered: true - 数据源指向共享数据库 - 设置instanceId自动生成 ``` --- #### **三、断电续跑容错层** **1. 续跑触发机制** ``` 恢复流程： 1. Quartz触发新执行请求 2. JobLauncher检测到相同参数的未完成JobInstance 3. 自动加载最后一次StepExecution的ExecutionContext 4. ItemReader通过open()方法定位到断点位置 ``` **2. 关键容错配置** ```properties 容错策略： - skipLimit: 10（允许跳过10次错误） - retryLimit: 3（瞬时错误重试次数） - noRollbackFor: NetworkTimeoutException（特定异常不回滚） ``` --- ### **执行时序流程** 1. **正常执行流程** ``` Quartz触发 → 创建新JobInstance → 从第0条开始处理 → 每100条提交事务 → 完成全部数据后更新状态为COMPLETED ``` 2. **断电恢复流程** ``` Quartz再次触发 → 检测到存在FAILED状态的JobInstance → 加载最后提交的ExecutionContext → ItemReader定位到第N*100条 → 继续处理后续数据 ``` --- ### **关键配置要点** | 模块 | 配置要点 | |-----------------|--------------------------------------------------------------------------| | **Spring Batch** | - 启用JdbcJobRepository<br>- 配置skip/retry策略<br>- 设置合理的chunk size | | **Quartz** | - 配置JDBC-JobStore<br>- 设置misfire策略为withExistingTrigger<br>- 定义持久化触发器 | | **数据库** | - 建立专用batch库<br>- 定期清理BATCH_*历史表<br>- 配置连接池参数 | --- ### **异常处理矩阵** | 异常类型 | 处理策略 | 恢复方式 | |-------------------------|-----------------------------------|------------------------| | 网络中断 | 重试3次 → 记录跳过 | 自动从断点续跑 | | 数据库死锁 | 立即重试 → 标记失败 | 人工介入 | | 文件IO错误 | 停止作业 → 记录最后处理位置 | 修复文件后重启 | | 业务数据校验失败 | 跳过当前记录 → 记录错误明细 | 继续处理后续数据 | --- ### **监控指标设计** 1. **关键监控项** - 每次chunk处理耗时百分位值（P90/P95） - 失败重启次数统计 - 跳过记录分类统计 - 作业执行周期波动监测 2. **健康检查端点** ```properties Spring Batch监控：/actuator/batchjobs Quartz监控：/actuator/quartz 自定义健康检查：/health/job-resume ``` --- ### **设计验证方法** 1. **断电模拟测试** - 在chunk处理期间强制关闭应用 - 验证重启后是否跳过已提交数据 - 检查ExecutionContext是否准确恢复 2. **负载压力测试** - 模拟10万条数据处理中断 - 记录状态恢复耗时（应<30秒） - 验证数据库锁竞争情况 --- 该设计方案通过三层协作实现**定时触发→批量处理→故障恢复**的完整闭环，关键点在于： 1. 状态存储与业务数据分离 2. 参数传递的幂等性控制 3. 分块处理与事务边界对齐 4. 集群环境下的状态同步 实际部署时建议配合APM工具（如SkyWalking）进行执行链路追踪，并设置作业执行超时阈值防止僵尸任务。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值