遇到过的坑

（1）不要重复造*，先看看自己的项目中是否有改功能，不要一口气就开始写

（2）架构方面：需要全量同步 和 增量同步 增量同步的方式可以使用kafka 但是要评估是否一定要增量同步，比如全量同步本身时间就很短，且消耗CPU和内存也一般，那这样是不是就没有增量的必要，多跑几次全量就是了。

（3）包冲突方面的根本原因是：有两个类，其类名和路径是一模一样的，导致编译器分辨不出是哪一个类来了，可通过查询类确认是由于哪几个包冲突引起的。

（4）catch不能乱用，对于该catch的部分进行catch，不该catch的不进行catch，即便有的catch住了，有的情况也应该进行throw，从而便于系统监控。

（5）ES 搜索 对于 OR 查询需要设定 timeout时间，从而避免超时。

（6）LTR算法的训练根据person系数和每一个参数的稀疏性，选择特征（不知道是否有效）

（7）LTR插件使用过程遇到的坑：1、master和data节点都需要重启 2、配置文件中打开script.search 3、关闭search_after

（8）在使用search_after时 不要轻易修改sort_values的个数，且sort_values中必须要包含一个doc的field

（9）有些类无法编译，显示引用包不存在，但是pom中已经引用了，原因可能是POM文件中引用jar有冲突导致的。

（10）口头确认需求（产品和leader）之后再做，免的做无用功，可以站在对方的角度，想想为什么做这件事，然后再做。

（11）在系统迁移项目中，要事先保留原有的项目，不要在原有的项目上修改，而应该新建立一个接口用于迁移，这样可以保证在迁移后出现问题可以顺利迁回。在迁移项目中，要预留对接时可能出现的接口不一致，架构问题等风险造成的延迟。

（12）elasticsearch中 put post 即便是同一个sourceid 如果未标明是update 操作就是一个insert 只是doc的version变了。

（13）因为字段名称写错误 show_times写成showtimes

（14）使用HTTPClient的时候，若是遇到Array类型进行透传，可使用add多个同样fieldname的数值，就变成了数组了。

（15）elasticsearch 查询耗cpu较少，建立索引耗cpu较多，如果CPU满负荷执行，考虑是不是建立索引任务有问题。

（16）不要在变化的查询的条件中轻易引用变量，因为变量值初始化之后值就不变了，除非重新赋值。