一场由 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 查到了。