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秒

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

3.问题解决

1. consumer端将重试次数设置为0，不重试
2. 事务注解加上超时时间的设置，超时时间小于接口定义的超时时间
3. 为了防止重复插入数据，增加业务幂等性操作，更新审核表状态时判断执行结果同时条件加上原状态值，使用数据库乐观锁方式，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 幂等性

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