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 幂等性

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

相关推荐
2401_8576100315 分钟前
Spring Boot框架:电商系统的技术优势
java·spring boot·后端
希忘auto31 分钟前
详解MySQL安装
java·mysql
冰淇淋烤布蕾42 分钟前
EasyExcel使用
java·开发语言·excel
拾荒的小海螺1 小时前
JAVA:探索 EasyExcel 的技术指南
java·开发语言
Jakarta EE1 小时前
正确使用primefaces的process和update
java·primefaces·jakarta ee
马剑威(威哥爱编程)1 小时前
哇喔!20种单例模式的实现与变异总结
java·开发语言·单例模式
用户3157476081351 小时前
成为程序员的必经之路” Git “,你学会了吗?
面试·github·全栈
java—大象2 小时前
基于java+springboot+layui的流浪动物交流信息平台设计实现
java·开发语言·spring boot·layui·课程设计
杨哥带你写代码2 小时前
网上商城系统:Spring Boot框架的实现
java·spring boot·后端
camellias_2 小时前
SpringBoot(二十一)SpringBoot自定义CURL请求类
java·spring boot·后端