好险，差点就是生产事故

最近接了一个需求，要对批量插入ES里的数据进行校验，需求比较简单，半天就把代码撸完了，开始自测，自测也很丝滑，上预发，查看预发日志，发现有WARN日志

WARN日志虽然没啥影响，本着精益求精的工匠精神，还是得处理一下。

定位代码，发现原来是使用了过期的方法

我们ES最近升级，从7.x升到了8.x，8.x不支持索引上加type了，这个代码应该是过去的老代码，然后看了一下过期的方法注释

这个简单，直接换一个构造方法

再次发到预发，WARN日志果然就不见了。

心里美滋滋。

开始提测。

测试测了一段时间，跟我反馈，页面存在大量的重复数据。我把页面打开，F12看一下接口，果然，有很多ID重复的数据，然后查数据源ES，发现很多_id不对的数据

正常来说，_id长这个样子

开始有一丢丢慌了。

然后根据重复的ID去查询ES，发现存在多条数据。这个不对劲，正常来说，ID是唯一的。

下意识的问了测试的同事，是不是动了ES的数据，测试给了我一个白眼，“谁没事动你的ES数据”。

测试的同事跟我反馈，执行批量操作之后就会产生重复数据。然后查看批量操作的代码，发现只有上面的那个改动。分析代码发现，修改前的代码和修改后的代码除了少了type参数，还少了id参数，我本来是想着source方法传入的map集合里面有id字段，应该会映射到_id上，然后查看IndexRequest的注释，发现更改后的方法需要手动指定id

也就是说，正确的写法应该是

改完之后，再发到预发，没有WARN日志，批量操作也不产生重复数据了。

还好测试及时发现了这个问题，要是没发现的话，发到生产，产生了大量重复数据，估计又得跑路了。

预发产生了很多脏数据，只能周末加班写个程序来删了。

有惊无险。。。