一个诡异的问题的解决20211008

近期一名同事发现了一个业务接口存在插入重复数据的问题，让我帮忙一起解决下，解决完了后感觉此问题有点意义，分享给大家。

接口功能

从OA系统下载报销单（报销单+报销明细+发票明细），存入ERP系统的费用模块

问题现象

出现重复记录（比如下载了1000条，到了费用模块变成了多于1000条，有记录重复的现象，没有固定的规律，重复的条数也不固定，记录里有插入的时间戳，时间差在毫秒级别），业务服务日志中没有错误。

业务逻辑

从OA系统下载数据，根据单据号查询本地数据库中已经存在的单据，将去重后的剩余单据插入数据库

解决过程

1、因为重复记录的插入时间很接近（毫秒级别差异），我首先排除了Dubbo的重试机制，感觉肯定是代码并发问题

2、看业务代码，结果并没有发现可疑代码，压根没有并发的代码

3、陷入僵局

4、测试环境加详细日志，根据logId的查询，发现了两个Dubbo线程号（26和27）使用了相同的logId（logId是一个在分布式系统中全局传递的字符串，会随着日志组件记录到日志中，也就是分布式链路追踪用的，生命周期从网关接到请求时产生，到网关响应后结束）

5、通过日志分析发现 26号线程是先出现的，27号线程是后出现的，之后两个线程同时运行

6、根据日志的记录知道了27号的线程是从网关进入的，再加上同一个logId的证据，所以推断此接口触发了网关重试机制

7、网关重试机制触发的临界点是30秒，如果后端业务接口30秒没有响应，网关会重新发起请求，使用相同的logId

8、还有疑问：为什么只重复个别的单据，并且没有规律，时多时少？ 为什么重复单据的插入时间戳如此接近？这无法解释啊

9、经过分析业务逻辑代码给出了答案：1）入库方法使用了自动提交事务（也就是没有开启事务），遍历集合插入，非批量插入  2）遍历集合前的一次去重操作。

10、由此得出了完整的事发过程

现场还原

前端向后端发起同步OA数据请求，前端堵塞等待响应，网关转发请求到业务服务，业务服务中dubbo 26号线程开始运行，下载OA数据，本地去重，本地存数据库过程中超过了30秒钟，网关重试机制触发，于是业务服务中27号线程开始执行同样的任务，（由于测试环境只启用了一份docker容器，所以两个线程都到了同一个jvm中）

它也进行了去重操作，由于方法没有开启事务，所以26号线程插入的数据都是实时生效的，所以27号线程通过去重的操作过滤了 大部分单据，只剩下了少量的单据进行插入操作，从而形成26号和27号几乎同时插入相同的单据信息，诡异的地方就是 这个业务表里的主键是一个独立的id自然主键，和业务数据无关，所以两个线程都可以插入成功，并且插入时间戳差异在毫秒级别。这就可以完全解释通上面的现象是如何造成的了。

问题总结

1、单据号列建立唯一索引，在数据库层面拒绝脏数据的产生，避免重复数据。

2、关于这种导数据的接口该不该加事务，没有一个绝对的答案，因为数据量大小不固定（上游接口提供的数据量不固定），我倾向于折中方案，数据量较大时 分批次提交事务，避免事务的过大或者过小。

3、同步操作改异步轮询状态来解决超时网关重试问题

4、去重操作还是需要的，这也是在保持接口的幂等

5、持久化没有事务+代码幂等去重操作+数据表没有建立唯一索引+重试机制 = 导致了此次诡异现象的发生。由于重复记录的时间戳非常接近，误导了最初的判断。

今天就到这里，感谢大家关注老吕架构。