一场由 ES 分片 routing 引发的问题
一场由 ES 分片 routing 引发的问题
ES 结构
{
"poroperties": {
"joinType": {
"type": "join",
"eager_global_ordinals": true,
"relations": {
"spu": "sku"
}
},
"id":{
"type": "keyword"
},
"spuGuid": {
"type": "keyword"
},
"skuGuid": {
"type": "keyword"
},
"sellCount": {
"type": "long"
}
}
}
我们使用 ES 存储商品数据,我们使用父子文档,字段为 joinType,其值为 sku 时则为子文档,id 为 skuGuid,其值为 spu 时则为父文档,id 为 spuGuid。使用父子文档是为了通过 sku 参数查询条件去查询 spu。
ES 在多分片多的情况下,必须将父子文档放在同一分片中,所以我们以 spuGuid 作为routing id。
问题描述
一段更新销量的代码执行完以后,查询发现销量未变化。
问题排查
查看 ES 数据
用 GET goods_index/_doc/7277857079027761152 直接查询该id的文档
用 POST goods_index/_search 条件为 skuGuid = 7277857079027761152
用 POST goods_index/_search 条件为 id = 7277857079027761152
这时候我还在怀疑是不是因为我们代码最近把主键都改为 long 数值类型,在序列化时变成了字符串类型,是否 es 对这个敏感。所以我又进行了一次查询,这次使用 id 字段,因为每个文档都会内置一个 id,然后就发现问题了。
这里居然出现了两个文档!,而且他们一个有 routing,一个没有 routing,我恍然大悟。我们的 ES 设置了分片数为 3,也就是每个文档都会根据 id 得到不同的 routing 值,从而存入不同的分片中。由于我们为了确保父子文档能正确查询,按照官方文档要求的将 spuGuid 设为 routing,但是在更新销量的代码中并没有指定 routing,没有指定的话,就会默认使用 id 作为 routing 依据,那就不知道会存入哪个分片了,运气好就是对的,运气差就是错的。这就解释了为什么一些商品的销量是正确的,一些是错误的问题。而且用 GET _doc 的方式查询时,它会默认用 id routing 一次再查询,所以查不到真正的文档,而查询到的那个只有一个销量的文档是代码中 upsert 插入的,upsert 是先如果没有找到对应文档就会插入文档,所以就只有一个字段。而在用 _search skuGuid = 7277857079027761152 查询时查不到是因为本来就没 skuGuid 这个字段。最后用 _search id = 7277857079027761152 查询到了,是因为用了文档本来的 id 查到了。
解决办法
ES更新的时候因为有分片存在,UpdateRequest 不设置 routing 时默认用 id 路由,如果用了父子文档(父子文档现在用的 spuGuid 作为routing id),就会路由错误,更新失败。
所以更新的时候如果用UpdateRequest,就必须指定routing;否则就用UpdateByQueryRequest,无需指定routing。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.kler.cn/a/590052.html 如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!