Elasticsearch系列---增量更新原理及优势

概要

本篇主要介绍增量更新(partial update，也叫局部更新)的核心原理，介绍6.3.1版本的Elasticsearch脚本使用实例和增量更新的优势。

增量更新过程与原理

简单回顾

前文我们有简单介绍过增量的语法，简单回顾一下请求示例：

POST /music/children/1/_update
{
  "doc": {
    "length": "76"
  }
}

一般从客户端到Elasticsearch，完整的应用请求流程基本是这样的：

客户端先发起GET请求，获取到document信息，展现到前端页面上，供用户进行编辑。
用户编辑完数据后，点击提交。
后台系统处理修改后的数据，并组装好完整的document报文。
发送PUT请求到ES，进行全量替换。
ES将老的document标记为deleted，然后重新创建一个新的document。

Elasticsearch的document是基于不可变模式设计的，所有的document更新，其实都创建了一个新的document出来，再把老的document标记为deleted，增量更新也不例外，只是GET全量document数据，整合新的document，替换老的document这三步操作全在一个shard里完成，毫秒级完成。

增量更新分片之间的交互

增量更新document的步骤：

Java客户端向ES集群发送更新请求。
Coodinate Node收到请求，但该document不在当前node上，它将请求转发到Node2节点的P0 shard上。
Node 2检索document，修改_source下的JSON，并且重新索引该document，如果有其他线程修改过该document，有版本冲突的话，会重新尝试更新document，最大重试retry_on_conflict次，超出重试次数后放弃。
如果步骤3操作成功，Node2会将该document的完整内容异步转发到Node1和Node3的replica shard，重新建立索引。一旦所有replica都返回成功，Node2返回成功消息给Coodinate Node。
Coodinate Node响应更新成功消息给客户端，此时ES集群内primary shard和replica shard都已经更新完成。

注意几点：

primary shard向replica shard进行document数据同步时，发送的是document的完整信息，因为异步请求不保证有序，如果发增量信息的话，顺序错乱会导致document内容错误。
只要Coodinate Node向Java客户端响应成功，就表示所有的primary shard向replica shard都完成了更新操作，此时ES集群内的数据是一致的，更新是安全的。
retry策略，ES再次获取document数据和最新版本号，成功就更新，失败再试，最大次数可以设置，如5次：retry_on_conflict=5
retry策略在增量操作无关顺序的场景更适用，比如说计数操作，谁先执行谁后执行，关系不大，最终结果是对的就行。其他的一些场景，如库存的变化，账户余额的变化，直接更新成指定数值的，肯定不能使用retry策略，但可以转化成加减法，如下单时由直接更新库存数量的逻辑改成“当前可用库存数量=库存数量-订单商品数量”，账户余额的更新加减变化的金额，这样可以在一定程度上，把顺序有关转化成顺序无关，就可以更方便的使用retry策略解决冲突的问题。

增量更新的优点

所有的查询、修改和回写操作，都是在ES内部完成的，减小了网络数据传输开销（2次），提升了性能。
相比全量替换的时间间隔（秒级以上），缩短了查询和修改的时间间隔（毫秒级），可以有效降低并发冲突的情况。

使用脚本实现增量更新

Elasticsearch支持使用脚本实现更为灵活的逻辑，6.0版本以后，默认支持的脚本是painless，并且不再支持Groovy，因为Groovy编译有一定概率会出现内存不释放，最终导致Full GC的问题。

我们以英文儿歌的案例为背景，假设document的数据是这样：

{
  "_index": "music",
  "_type": "children",
  "_id": "2",
  "_version": 6,
  "found": true,
  "_source": {
    "name": "wake me, shark me",
    "content": "don't let me sleep too late, gonna get up brightly early in the morning",
    "language": "english",
    "length": "55",
    "likes": 0
  }
}

内置脚本

现在有这样一个需求：每当有人点击播放一次歌曲时，该document的likes field就自增1，我们可以用简单的脚本来实现：

POST /music/children/2/_update
{
   "script" : "ctx._source.likes++"
}

执行一次后，再查询该document，发现likes变成1，每执行一次，likes都自增1，结果符合预期。

外部脚本

对刚刚那个自增需求做一些改动，支持批量更新播放量，自增的数量由参数传入，脚本也可以通过导入的方式，预先编译存储在ES中，使用的时候调用即可。

创建脚本

POST _scripts/music-likes
{
  "script": {
    "lang": "painless",
    "source": "ctx._source.likes += params.new_likes" 
  }
}

脚本ID为music-likes，参数为new_likes，是可以在调用时传入的。

使用脚本

我们更新时，执行如下请求，就可以调用刚刚创建的脚本

POST /music/children/2/_update
{
  "script": {
    "id": "music-likes", 
    "params": {
      "new_likes": 2
    }
  }
}

id即创建脚本时的music-likes，params是固定写法，里面的参数为new_likes，执行后再查看document信息，可以看到likes field的值按传入的值进行累加，结果符合预期。

查看脚本

命令：

GET _scripts/music-likes

斜杠后面的参数即脚本ID

删除脚本

命令：

DELETE _scripts/music-likes

斜杠后面的参数即脚本ID

脚本注意事项

ES检测到新脚本时，会执行脚本编译，并将它存储在缓存中，编译比较耗时。
脚本的编写能参数化的，就不要硬编码，提高脚本的复用性。
短时间内太多的脚本编译，如果超出了ES的承受范围，ES直接报circuit_breaking_exception错误，这个范围默认是15条/分钟。
脚本缓存默认100条，默认不设过期时间，每个脚本最大字符65535字节，想自行配置的话可以改script.cache.expire、script.cache.max_size和script.max_size_in_bytes参数。

一句话，提高脚本的复用性。

upsert语法

像刚刚的案例，实现的是一个播放计数器的功能，目前这个计数器是与内容存储在一起，如果计数器单独存储，可能会出现新上架的一首歌，但计数器的document可能还不存在，试图对它做更新操作会报document_missing_exception错误，这种场景我们需要使用upsert语法：

POST /music/children/3/_update
{
   "script" : "ctx._source.likes++",
   "upsert": {
     "likes": 0
   }
}

如果id为3的记录不存在，第一次请求时，执行upsert里面的JSON内容，初始化一个新文档，ID为3，likes值为0；第二次请求时，文档已经存在，此时做script脚本的更新操作，likes自增。

小结

本篇简单介绍了增量更新的过程与原理，并与全量替换做了简单的对比，针对一些简单的计数场景，引入脚本的实现方式案例，脚本可以实现很丰富的功能，具体可以查看官网对Painless的介绍。

专注Java高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java架构社区

概要