记录一次在单位里做的删除优化，使用delete_by_query的时候发现了一个问题，就是删除效率太低。当打流日志并发变高的时候，删除往往跟不上ES数据增加的速度，导致磁盘占用率过高。
第一版尝试调整过相关代码的删除阈值，发现ES会在查询到大数据量的情况下删除失败，后面经过定位发现是并发写入和删除产生的版本冲突问题。
//新增conflicts=proceed.delete_by_query?conflicts=proceed
经过修改后，发现虽然解决了版本冲突导致的删除中断问题，但是在某些极端情况下还是会删除超时。
查询了一下官方文档，发现了2种解决方案
一种是ES的异步删除，返回一个taskId。
另外一种是多线程删除。
经过实际测试，决定使用第二种方式来应对当下的业务场景。
在代码中新增
scroll_size//这个参数是执行删除的时候，每次每个线程会查询的数据量，然后进行删除。//默认是100，就是说每个线程每次都会查询出100条数据然后再删除。slices//这个就相当于开启的线程数，同时会有多少个线程执行查询然后删除程序。//默认是1，就是同时只会有一个线程进行查询删除操作。delete_by_query?conflicts=proceed&scroll_size=5000&slices=10
注意：以上这2个值对于不同性能的机器往往是不一样的，以上的只是参考值，我们可以根据实际测试情况，比如删除多少数据，用多少线程，共计多少时间，来设置最符合我们当下业务的线程。
