Seata全局事务开启后,Mysql 批量Insert耗时变长的问题

文章讨论了在使用Seata解决分布式系统事务时,遇到的RPCTimeout问题,尤其是在插入大量数据(8万条)时。作者发现去掉分布式事务后性能显著提升,提示在处理大规模数据批量插入时应避免全局事务。

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

Seata解决了分布式系统的事务问题,但是在某些场景下仍然存在一些问题。今天就又遇到了一个。

我的环境 dubbo + seata + mysql。

相关版本:

  • dubbo:2.7.15
  • seata:1.6.1
  • mysql:5.7

场景:有个接口,功能为生成8万条数据 insert 到一张表中,因为除了insert 操作外还有其他更新操作,所以在主调方法上加上了 @GlobalTransactional 注解,其他子分支的事务添加 @Transactional 注解。

下面是伪代码,

@DubboReference
private MyService myService;

// 调用端,dubbo消费者,声明全局事务
@GlobalTransactional
public void operation() {
    // 生成8万条数据,insert到table_a表中(rpc远程调用)
    List<Integer> list = generateData();
    myService.deal(list);

    // 其他操作(rpc远程调用)
    // …………
}

//======================项目分隔线(上下的代码分属两个项目)=====================

// dubbo服务提供者,添加分支事务
@Autowired
TableAMapper tableAMapper;

@Transactional
public void deal(List<Integer> list) {
    List<List<Integer>> splitList = ListUtil.split(list, 1000);
    for (List<Integer> subList : splitList) {
        tableAMapper.batchInsert(subList);
    }
}

在分支事务中,为了防止单次batch insert 的数据过多导致报错,所以将 insert 数据切割成1000条一份,分批执行。

然后,就报错了

ERROR o.a.dubbo.rpc.filter.ExceptionFilter -  [DUBBO] Got unchecked and undeclared exception which called by 10.243.119.10. service: com.hml.user.MyService, method: deal, exception: org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: io.seata.core.exception.RmTransactionException: RPC Timeout, dubbo version: 2.7.15, current host: 10.243.119.168
org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: io.seata.core.exception.RmTransactionException: RPC Timeout
	at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:332)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:743)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:711)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:632)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:386)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:691)
	at org.apache.dubbo.common.bytecode.Wrapper39.invokeMethod(Wrapper39.java)
	at org.apache.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:47)
	at org.apache.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:84)
	at org.apache.dubbo.config.invoker.DelegateProviderMetaDataInvoker.invoke(DelegateProviderMetaDataInvoker.java:56)
	at org.apache.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:56)
	at com.alibaba.dubbo.rpc.Invoker$CompatibleInvoker.invoke(Invoker.java:55)
	at io.seata.integration.dubbo.alibaba.AlibabaDubboTransactionPropagationFilter.invoke(AlibabaDubboTransactionPropagationFilter.java:45)
	at com.alibaba.dubbo.rpc.Filter.invoke(Filter.java:29)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.protocol.dubbo.filter.TraceFilter.invoke(TraceFilter.java:77)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.TimeoutFilter.invoke(TimeoutFilter.java:46)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.seata.SeataTransactionPropagationProviderFilter.invoke(SeataTransactionPropagationProviderFilter.java:66)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:91)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:52)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.GenericFilter.invoke(GenericFilter.java:192)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.ClassLoaderFilter.invoke(ClassLoaderFilter.java:38)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.EchoFilter.invoke(EchoFilter.java:41)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.filter.ContextFilter.invoke(ContextFilter.java:129)
	at org.apache.dubbo.rpc.protocol.FilterNode.invoke(FilterNode.java:61)
	at org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol$1.reply(DubboProtocol.java:148)
	at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequest(HeaderExchangeHandler.java:100)
	at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:175)
	at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:51)
	at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.dubbo.common.threadlocal.InternalRunnable.run(InternalRunnable.java:41)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: io.seata.core.exception.RmTransactionException: RPC Timeout
	at io.seata.rm.datasource.ConnectionProxy.recognizeLockKeyConflictException(ConnectionProxy.java:161)
	at io.seata.rm.datasource.ConnectionProxy.processGlobalTransactionCommit(ConnectionProxy.java:252)
	at io.seata.rm.datasource.ConnectionProxy.doCommit(ConnectionProxy.java:230)
	at io.seata.rm.datasource.ConnectionProxy.lambda$commit$0(ConnectionProxy.java:188)
	at io.seata.rm.datasource.ConnectionProxy$LockRetryPolicy.doRetryOnLockConflict(ConnectionProxy.java:356)
	at io.seata.rm.datasource.ConnectionProxy$LockRetryPolicy.execute(ConnectionProxy.java:348)
	at io.seata.rm.datasource.ConnectionProxy.commit(ConnectionProxy.java:187)
	at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:329)
	... 51 common frames omitted
Caused by: io.seata.core.exception.RmTransactionException: RPC Timeout
	at io.seata.rm.AbstractResourceManager.branchRegister(AbstractResourceManager.java:73)
	at io.seata.rm.DefaultResourceManager.branchRegister(DefaultResourceManager.java:96)
	at io.seata.rm.datasource.ConnectionProxy.register(ConnectionProxy.java:273)
	at io.seata.rm.datasource.ConnectionProxy.processGlobalTransactionCommit(ConnectionProxy.java:250)
	... 57 common frames omitted
Caused by: java.util.concurrent.TimeoutException: null ,cost: 15000 ms
	at io.seata.core.protocol.MessageFuture.get(MessageFuture.java:65)
	at io.seata.core.rpc.netty.AbstractNettyRemotingClient.sendSyncRequest(AbstractNettyRemotingClient.java:174)
	at io.seata.rm.AbstractResourceManager.branchRegister(AbstractResourceManager.java:67)
	... 60 common frames omitted

RPC Timeout,调用超时了。

8万条数据,每1千条一次 insert 的话,需要执行 80 次,也不至于15秒还执行不下来吧?

抱着对seata存疑的态度,将 @GlobalTransactional 去掉了,不要分布式事务了。结果整个接口4秒就执行完了。

可见seata肯定干了什么特别耗时的事情。具体哪里耗的时,暂且不跟了,反正记住这个用法就得了:一条 insert 语句插入多条数据的时候,尤其是可能数据量很大,需要在一次事务中多次执行 insert 时,不要加分布式事务

<think>好的,我现在需要处理用户关于“事务消失场景”的查询。首先,我要确定用户所指的具体领域。事务消失可能出现在多个技术领域,比如数据库分布式系统、微服务或者编程框架中。用户之前询问过“nm”的含义,涉及纳米单位、Linux工具等,现在转向事务消失,可能是在开发或系统设计中遇到了问题。 接下来,我需要明确事务消失的具体定义。事务消失通常指事务未按预期执行,如未提交、回滚或中间状态丢失。这可能由多种原因引起,比如事务隔离级别问题、超时、资源竞争或系统故障。需要覆盖不同的场景,并提供解决方案,确保用户能理解问题根源和应对方法。 用户可能是在开发过程中遇到了事务未生效的情况,比如数据库操作没有持久化,或者分布式系统中事务状态不一致。需要分场景讨论,比如数据库事务、分布式事务、框架中的事务管理,以及并发和超时问题。每个场景需要具体的原因分析和解决方案,帮助用户逐步排查问题。 考虑到用户之前的问题涉及Linux工具,他们可能有技术背景,需要详细的技术解释和实际案例。要确保回答结构清晰,分点列出,使用示例代码或配置建议,比如Spring的事务注解或数据库隔离级别设置。同时,提醒用户注意事务日志和监控的重要性,预防事务消失的问题。 最后,检查是否需要补充其他可能的事务消失场景,比如网络分区、消息队列的事务消息丢失,或者缓存与数据库不一致的情况。确保覆盖常见原因,并提供全面的解决方案,帮助用户彻底理解和解决实际问题。</think>以下是事务消失场景的典型分类及技术解析: ===================== 一、数据库事务消失 ===================== 1. **自动提交模式误用** - 现象:单条SQL执行后未显式提交 - 原因:MySQL数据库默认`autocommit=1` - 示例: ```sql START TRANSACTION; -- 显式开启事务 INSERT INTO users VALUES(...); -- 执行操作 -- 未执行COMMIT直接断开连接 ``` 2. **事务隔离级别导致** - 幻读场景(隔离级别< SERIALIZABLE): ```sql -- Session A BEGIN; SELECT * FROM products WHERE stock > 0; -- 返回10条记录 -- Session B COMMIT; 删除所有库存<=0的记录 -- Session A再次查询可能得到不同结果 ``` ===================== 二、分布式事务丢失 ===================== 1. **两阶段提交故障** ```mermaid graph LR A[协调者] --> B[参与者1] A --> C[参与者2] 协调者发送prepare后宕机 --> 参与者资源锁定但未提交 ``` 2. **最终一致性设计缺陷** - 典型案例:订单支付成功但库存未扣减 - 错误时序: ``` 1. 扣减库存(本地事务) 2. 发送MQ消息失败 3. 支付状态无法同步 ``` ===================== 三、框架层事务失效 ===================== 1. **Spring声明式事务失效场景** - 自调用问题: ```java @Service public class OrderService { public void createOrder() { this.updateStock(); // 事务注解失效 } @Transactional public void updateStock() { // 库存操作 } } ``` - 异常类型不匹配: ```java @Transactional(rollbackFor = Exception.class) public void process() throws IOException { // 抛出IOException不会被回滚(默认只回滚RuntimeException) } ``` ===================== 四、并发场景事务覆盖 ===================== 1. **丢失更新问题** ```sql -- 线程A START TRANSACTION; SELECT balance INTO @bal FROM accounts WHERE id=1; -- 读取100 -- 线程B START TRANSACTION; SELECT balance INTO @bal FROM accounts WHERE id=1; SET @bal = @bal - 20; UPDATE accounts SET balance = @bal WHERE id=1; COMMIT; -- 余额变为80 -- 线程A继续执行 SET @bal = @bal + 50; UPDATE accounts SET balance = @bal WHERE id=1; COMMIT; -- 错误覆盖为150(正确应为130) ``` ===================== 五、预防与解决方案 ===================== 1. **技术防御措施** - 数据库层: ```sql SELECT ... FOR UPDATE -- 悲观锁 UPDATE table SET col=val WHERE version=@old_version -- 乐观锁 ``` - 应用层: ```java @Transactional(isolation = Isolation.SERIALIZABLE) public void criticalOperation() {...} ``` 2. **架构设计建议** - 分布式事务采用Saga模式: ```mermaid graph LR A[订单服务] -->|CreateOrder| B[支付服务] B -->|成功| C[库存服务] C -->|失败| D[补偿操作] ``` 3. **监控关键指标** ``` db_transaction_duration_seconds{quantile="0.95"} // 事务耗时 db_deadlocks_total // 死锁次数 app_transaction_rollback_total{type="timeout"} // 超时回滚 ``` 建议结合具体技术栈(如MySQL/PostgreSQL、Spring/Seata等)分析事务日志,使用`SHOW ENGINE INNODB STATUS`或分布式链路追踪工具定位具体消失环节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值