架构原理
本文作为 Elastic Stack 指南,关注于 Elasticsearch 在日志和数据分析场景的应用,并不打算对底层的 Lucene 原理或者 Java 编程做详细的介绍,但是 Elasticsearch 层面上的一些架构设计,对我们做性能调优,故障处理,具有非常重要的影响。
所以,作为 ES 部分的起始章节,先从数据流向和分布的层面,介绍一下 ES 的工作原理,以及相关的可控项。各位读者可以跳过这节先行阅读后面的运维操作部分,但作为性能调优的基础知识,依然建议大家抽时间返回来了解。
文本整理自《ELKstack权威指南》,需要的小伙伴可以在文末查看领取方式、
带着问题学习
- 写入的数据是如何变成elasticsearch里可以被检索和聚合的索引内容的?
- lucene如何实现准实时索引?
- 什么是segment?
- 什么是commit?
- segment的数据来自哪里?
- segment在写入磁盘前就可以被检索,是因为利用了什么?
- elasticsearch中的refresh操作是什么?配置项是哪个?设置的命令是什么?
- refresh只是写到了文件系统缓存,那么实际写入磁盘是由什么控制呢?,如果这期间发生错误和故障,数据会不会丢失?
- 什么是translog日志?什么时候会被清空?什么是flush操作?配置项是什么?怎么配置?
- 什么是段合并?为什么要段合并?段合并线程配置项?段合并策略?怎么forcemerge(optimize)?
- routing的规则是什么样的?replica读写过程?wait_for_active_shards参数timeout参数 ?
- reroute 接口?
- 两种 自动发现方式?
文本整理自《ELKstack权威指南》,需要的小伙伴可以添加小助手VX:xuanwo008获取。
segment、buffer和translog对实时性的影响
既然介绍数据流向,首先第一步就是:写入的数据是如何变成 Elasticsearch 里可以被检索和聚合的索引内容的?
以单文件的静态层面看,每个全文索引都是一个词元的倒排索引,具体涉及到全文索引的通用知识,这里不单独介绍,有兴趣的读者可以阅读《Lucene in Action》等书籍详细了解。
动态更新的 Lucene 索引
以在线动态服务的层面看,要做到实时更新条件下数据的可用和可靠,就需要在倒排索引的基础上,再做一系列更高级的处理。
其实总结一下 Lucene 的处理办法,很简单,就是一句话:新收到的数据写到新的索引文件里。
Lucene 把每次生成的倒排索引,叫做一个段(segment)。然后另外使用一个 commit 文件,记录索引内所有的 segment。而生成 segment 的数据来源,则是内存中的 buffer。也就是说,动态更新过程如下:
- 当前索引有 3 个 segment 可用。索引状态如图 2-1; 图 2-1
- 新接收的数据进入内存 buffer。索引状态如图 2-2; 图 2-2
- 内存 buffer 刷到磁盘,生成一个新的 segment,commit 文件同步更新。索引状态如图 2-3。 图 2-3
利用磁盘缓存实现的准实时检索
既然涉及到磁盘,那么一个不可避免的问题就来了:磁盘太慢了!对我们要求实时性很高的服务来说,这种处理还不够。所以,在第 3 步的处理中,还有一个中间状态:
- 内存 buffer 生成一个新的 segment,刷到文件系统缓存中,Lucene 即可检索这个新 segment。索引状态如图 2-4。 图 2-4
- 文件系统缓存真正同步到磁盘上,commit 文件更新。达到图 2-3 中的状态。
这一步刷到文件系统缓存的步骤,在 Elasticsearch 中,是默认设置为 1 秒间隔的,对于大多数应用来说,几乎就相当于是实时可搜索了。Elasticsearch 也提供了单独的 /_refresh 接口,用户如果对 1 秒间隔还不满意的,可以主动调用该接口来保证搜索可见。
注:5.0 中还提供了一个新的请求参数:?refresh=wait_for,可以在写入数据后不强制刷新但一直等到刷新才返回。
不过对于 Elastic Stack 的日志场景来说,恰恰相反,我们并不需要如此高的实时性,而是需要更快的写入性能。所以,一般来说,我们反而会通过 /_settings 接口或者定制 template 的方式,加大 refresh_interval 参数:
# curl -XPOST http://127.0.0.1:9200/logstash-2015.06.21/_settings -d' { "refresh_interval": "10s" } '
如果是导入历史数据的场合,那甚至可以先完全关闭掉:
# curl -XPUT http://127.0.0.1:9200/logstash-2015.05.01 -d' { "settings" : { "refresh_interval": "-1" } }'
在导入完成以后,修改回来或者手动调用一次即可:
# curl -XPOST http://127.0.0.1:9200/logstash-2015.05.01/_refresh
translog 提供的磁盘同步控制
既然 refresh 只是写到文件系统缓存,那么第 4 步写到实际磁盘又是有什么来控制的?如果这期间发生主机错误、硬件故障等异常情况,数据会不会丢失?
这里,其实有另一个机制来控制。Elasticsearch 在把数据写入到内存 buffer 的同时,其实还另外记录了一个 translog 日志。也就是说,第 2 步并不是图 2-2 的状态,而是像图 2-5 这样:
图 2-5
在第 3 和第 4 步,refresh 发生的时候,translog 日志文件依然保持原样,如图 2-6:
图 2-6
也就是说,如果在这期间发生异常,Elasticsearch 会从 commit 位置开始,恢复整个 translog 文件中的记录,保证数据一致性。
等到真正把 segment 刷到磁盘,且 commit 文件进行更新的时候, translog 文件才清空。这一步,叫做 flush。同样,Elasticsearch 也提供了 /_flush 接口。