近期一名同事发现了一个业务接口存在插入重复数据的问题,让我帮忙一起解决下,解决完了后感觉此问题有点意义,分享给大家。
接口功能
从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、持久化没有事务+代码幂等去重操作+数据表没有建立唯一索引+重试机制 = 导致了此次诡异现象的发生。由于重复记录的时间戳非常接近,误导了最初的判断。
今天就到这里,感谢大家关注老吕架构。