我在查询es的时候,第一次根据时间范围(截止时间是当前时间精确到秒),查询出来100条数据,以他们的tranceid作为第二次查询的条件;
第二次查询,根据上次的100个tranceid(不约束时间范围)查询,但是结果不到100条,并且每次查询结果都不相同(不一定递增),一分钟左右后恢复正常,能查询出100条数据
我把第二次的语句打印出来去kibana去查询,也是相同的情况每次查询结果都不相同(不一定递增),一分钟左右后恢复正常,能查询出100条数据。
猜想:
会是es的事实性问题么?我记得es的简介有一句是可以近乎实时的查询数据,es集群中节点数据的同步可能会影响到这个。
解答:
es的index刷盘时间被设置成了1分钟,最近一分钟的数据还没有全部同步成功,所以造成数据不全,而且有些数据是在缓存里
可能上一秒搜索到下一秒就消失,所以查询出来的数据并不是递增的。
进一步疑问:
那第一次调用链查询到的前100个traceid是如何查到的?如果你能查到,还和ES的落盘时间还有关系吗
解答:
因为那个查出来的100个可能是几万个里面符合的返回最靠近截至时间的100个,而且点击两次,两次的100个id还可能会不同说明数据也是在变化和开能说的读取的既有缓存的数据也有内存的数据也吻合,但是第二次查询相当于指定了这100个,一旦没有落盘,就会少于100 。
解决方案:
把刷盘时间改成30s,查询时间可以往前推1分钟就基本满足99%的数据,解决了问题。但是日志消费有时延不在这个范围内。