在我的上篇文章ES 脚本介绍中介绍了ES 脚本的基本概念和使用,而本文将对其内部实现做一个分析。
本文的分析使用的ES源码为6.4.3版本。
在分析前,我们先来看一个在ES update API中使用脚本文档进行更新的例子:
POST test/_update/1
{
"script" : {
"source": "ctx._source.counter += params.count",
"lang": "painless",
"params" : {
"count" : 4
}
}
}
此API中定义了一个脚本:
counter
的值加上参数count的值接下来,我们从update API的入口出发,来看这个脚本最终是如何被执行的。
每个Rest接口都有uri和相应的RestAction,在构造函数中被注册,对更新接口来说,其uri格式和RestAction分别是:/{index}/{type}/{id}/_update
和RestUpdateAction
请求在RestUpdateAction
的prepareRequest方法中被简单处理后,经过NodeClient
转发,最终在TransportUpdateAction
类中执行实际操作。
大部分RestAction只负责转发,实际则由相应的TransportAction处理
由于更新是单(single)操作,在TransportUpdateAction
将通过TransportInstanceSingleOperationAction
:查找请求中的文档id对应shard,再转发给拥有相应shard的node去执行,见TransportInstanceSingleOperationAction:170
行:
转发的请求最终进入TransportUpdateAction
类的shardOperation
方法。
在shardOperation方法中,执行的操作为:
而在第一步调用updateHelper.prepare
时,会根据更新API的请求内容,构造更新后的文档内容:
对于脚本请求,则调用prepareUpdateScriptRequest
方法处理文档。
prepareUpdateScriptRequest方法
executeScript方法:
更新脚本属于其中一种可执行脚本ExecutableScript,其它的还包括:
在单独分析更新脚本的执行后,这里我们再来剖析ES的脚本框架。
对于在不同类型API中执行的脚本,其执行方式也有所不同(包括返回值类型、参数等不同),ES为其都声明了相应的interface。比如上述的Update API中的脚本对应于ExecutableScript interface。
其他interface还包括:FilterScript(用于query filter)、IngestScript(用于Ingest Script Processor)、SearchScript(用于搜索、聚合等请求中的请求)等
在上述executeScript方法中可以看到,更新接口中的脚本是通过scriptService.compile方法编译的。实际上,所有API中的脚本、所有的脚本语言,也都是通过此方法编译的。其内部逻辑主要包括:
ScriptService类内部封装了用于执行不同脚本语言的执行引擎ScriptEngine,实现类包括PainlessScriptEngine
、ExpressionScriptEngine
和MustacheScriptEngine
。
这里以Painless脚本语言为例进行分析。在ScriptService中会调用相应语言ScriptEngine的compile方法,以下为PainlessScriptEngine的compile方法实现:
对于可执行脚本,其执行逻辑为:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。