Troubleshooting系列-接口超时导致的重复数据插入问题分析及解决

1.问题现象

现网巡检发现一个接口MethodA超时,执行时间大概花了14秒。查看接口对应的数据,发现有张表TA数据重复。

2.问题定位分析过程

MethodA接口是一个管理台优惠券批次增加可用商品审核接口,审核通过后会将对应商品添加到批次可用商品表中。

分析ELK中日志记录,发现出问题的MethodA调用了两次,其原因是DUBBO默认调用超时后会重试两次,第一次超时后进行重试触发,这样会调用两次。整体时序类似如下:

关于MethodA超时时间配置

dubbo调用超时时间优先级是:对于同一个服务,方法级别>服务级别>全局级别,消费端配置优先于提供端配置。如果级别一样,离调用者越近,优先级越高。

消费者端调用接口的超时时间10s,服务端接口一旦调用,不会取消,因tranctional超时时间没配置,需要等整个事务完成才会结束,在provider端需要14秒,但是cosumer端等待10秒后就会重试一次,第二次大概率会成功。

但是在验证时,请求1'有时10秒就会超时,原因是跑到更新审核表状态时,因请求1将行锁锁住,如果超过10秒不返回,会触发单条sql执行超时,有连接请求sockettimeout指定,刚好也是10秒

sql 复制代码
update t_1 set status = '2' where audit_id = '123';
//audit_id是唯一主键,更新成功,触发行锁,如果更新行数为0,会触发间隙锁

3.问题解决

  1. consumer端将重试次数设置为0,不重试
  2. 事务注解加上超时时间的设置,超时时间小于接口定义的超时时间
  3. 为了防止重复插入数据,增加业务幂等性操作,更新审核表状态时判断执行结果同时条件加上原状态值,使用数据库乐观锁方式,sql改成如下
sql 复制代码
update t_1 set status = '2' where audit_id = '123' and status='1';

这样保证请求1'进来时,如果请求1已经完成,更新数据行数为0

4. 其他知识

4.1 dubbo默认重试次数

参考 服务重试

4.2 dubbo超时时间

消费者Method>提供者method>消费者Reference>提供者Service>消费者全局配置provider>提供者全局配置consumer

参考在 Provider 端尽量多配置 Consumer 端属性

4.3 幂等性

高并发下如何保证接口的幂等性?

相关推荐
Grey Zeng5 小时前
Java SE 25新增特性
java·jdk·jdk新特性·jdk25
追逐时光者6 小时前
精选 4 款基于 .NET 开源、功能强大的 Windows 系统优化工具
后端·.net
雨白6 小时前
Java 线程通信基础:interrupt、wait 和 notifyAll 详解
android·java
TF男孩6 小时前
ARQ:一款低成本的消息队列,实现每秒万级吞吐
后端·python·消息队列
bobz9657 小时前
进程和线程结构体的统一和差异
面试
AAA修煤气灶刘哥8 小时前
别让Redis「歪脖子」!一次搞定数据倾斜与请求倾斜的捉妖记
redis·分布式·后端
AAA修煤气灶刘哥8 小时前
后端人速藏!数据库PD建模避坑指南
数据库·后端·mysql
你的人类朋友8 小时前
什么是API签名?
前端·后端·安全
昵称为空C10 小时前
SpringBoot3 http接口调用新方式RestClient + @HttpExchange像使用Feign一样调用
spring boot·后端
架构师沉默10 小时前
设计多租户 SaaS 系统,如何做到数据隔离 & 资源配额?
java·后端·架构