记录一次增量数据一致性问题

最近收到客户投诉出现数据无法操作的问题，经过排查，Mysql 和 ES 数据出现一致性问题。我们的使用场景是定于 Mysql binlog 投递到 Kafka，增量服务顺序消费 Kafka 中的消息，更新 ES 中的文档。

索引结构

在分析问题前先简单看下索引结构，这里只看出现问题的字段，主要就是用于存储标签 id 的一个 long 类型的字段，存的是一个数组。

json 复制代码

{
  "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 脚本更新，因为更新操作是可以直接更新内存的数据，所以数据是实时的。

json 复制代码

{
  "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 是旧的了。

记录一次增量数据一致性问题

索引结构

问题分析

解决方案

参考