最近收到客户投诉出现数据无法操作的问题，经过排查，Mysql 和 ES 数据出现一致性问题。我们的使用场景是定于 Mysql binlog 投递到 Kafka，增量服务顺序消费 Kafka 中的消息，更新 ES 中的文档。
索引结构
在分析问题前先简单看下索引结构，这里只看出现问题的字段，主要就是用于存储标签 id 的一个 long 类型的字段，存的是一个数组。
{
"mappings" : {
"f_tag_id" : {
"type" : "long"
},
"f_status" : {
"type" : "byte"
}
}
}
问题分析
- 先简单看一下标签增量的逻辑，由于标签存的是一个数组，所以在更新的时候是先把文档查询出来，再对相应的数组字段做元素的新增或者删除，然后再重新索引到 ES 中。
- 生产中的场景是同时有两个 binlog 并发，但是是分两次消费（同一批次的消息我们这边会在内存进行组装），A 表的 binlog 先更新 f_status，B 表 (标签关联表) 的 binlog 先将文档查询出来，更新完之后再将整个文档索引回 ES（更新代码通用性，所以是更新整个文档）。
- 由于 ES 索引更新刷盘并非实时的，导致 B 表查询出来的文档是旧的，所以 B 表在更新索引时将旧的数据覆盖了新的数据。
- 举一个简单的例子：
- 假设原本 f_status = 0, f_tag_id = []
- A 表更新 f_status =1，此时 f_status = 1, f_tag_id = []
- B 表更新 f_tag_id = [1]，由于 ES 刷盘存在延迟，导致更新的数据为 f_status = 0, f_tag_id = [1]
解决方案
- 最初的想法是只更新 f_tag_id 字段，但是这样其实还是会有问题，举个例子 B 表 (标签关联表) 针对同一条记录两个标签关联数据，意味着会有两个 binlog 生成，假设很不巧，Kafka 消费者分了两个批次去更新索引，就会造成和上述类似的场景。
- 假设原本 f_tag_id = [1,2]
- 第一条 binlog 更新 f_tag_id = [1,2,3]
- 第二条 binlog 消费时，先查询 f_tag_id = [1,2]，此时在去更新 f_tag_id 就会变成 [1,2,4]，还是会出现数据不一致问题
- 第一个方案行不通，那能不能让 f_tag_id 像更新其他字段一样，不需要先查询出来组装再重新索引回 ES，答案是可以，那就是利用 ES 脚本更新，因为更新操作是可以直接更新内存的数据，所以数据是实时的。
{
"script": {
"source": """
List tagIdList = ctx._source.f_tag_id == null
? new ArrayList()
: ctx._source.f_tag_id;
if("insert".equals(params.method)
&& !tagIdList.contains(params.changeTagId)){
tagIdList.add(params.changeTagId);
} else if("delete".equals(params.method)
&& tagIdList.contains(params.changeTagId)){
tagIdList.remove(tagIdList.indexOf(params.changeTagId));
}
ctx._source.f_tag_id = tagIdList;
""",
"lang": "painless",
"params": {
"changeTagId": 12,
"method": "insert"
}
},
"upsert": {
"f_tag_id": [12]
}
}
- 大概思路就是利用脚本直接针对 f_tag_id 进行元素变更，这样就不用担心查出来的 f_tad_id 是旧的了。
