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

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

相关推荐
郑祎亦23 分钟前
Spring Boot 项目 myblog 整理
spring boot·后端·java-ee·maven·mybatis
不是二师兄的八戒23 分钟前
本地 PHP 和 Java 开发环境 Docker 化与配置开机自启
java·docker·php
爱编程的小生35 分钟前
Easyexcel(2-文件读取)
java·excel
本当迷ya36 分钟前
💖2025年不会Stream流被同事排挤了┭┮﹏┭┮(强烈建议实操)
后端·程序员
带多刺的玫瑰1 小时前
Leecode刷题C语言之统计不是特殊数字的数字数量
java·c语言·算法
陪学1 小时前
百度遭初创企业指控抄袭,维权还是碰瓷?
人工智能·百度·面试·职场和发展·产品运营
计算机毕设指导62 小时前
基于 SpringBoot 的作业管理系统【附源码】
java·vue.js·spring boot·后端·mysql·spring·intellij-idea
Gu Gu Study2 小时前
枚举与lambda表达式,枚举实现单例模式为什么是安全的,lambda表达式与函数式接口的小九九~
java·开发语言
Chris _data2 小时前
二叉树oj题解析
java·数据结构
牙牙7052 小时前
Centos7安装Jenkins脚本一键部署
java·servlet·jenkins