[大数据]ElasticSearch探索之路（五）集群与分片：选举、动态更新、近实时搜索、事务日志、段合并

集群内部原理

集群与节点

一个运行中的Elasticsearch实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

由于Elasticsearch采用了主从模式，所以当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 因为主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。

作为用户，我们可以将请求发送到集群中的任何节点（这个处理请求的节点也叫做协调节点）。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。

分片

在分布式系统中，单机无法存储规模巨大的数据，要依靠大规模集群处理和存储这些数据，一般通过增加机器数量来提高系统水平扩展能力。因此，需要将数据分成若干小块分配到各个机器上。然后通过某种路由策略找到某个数据块所在的位置。

分片（shard）是底层的基本读写单元，分片的目的是分割巨大索引，让读写可以并行操作，由多台机器共同完成。读写请求最终落到某个分片上，分片可以独立执行读写工作。Elasticsearch利用分片将数据分发到集群内各处。分片是数据的容器，文档保存在分片内，不会跨分片存储。分片又被分配到集群内的各个节点里。当集群规模扩大或缩小时，Elasticsearch会自动在各节点中迁移分片，使数据仍然均匀分布在集群里。

为了应对并发更新问题，Elasticsearch将分片分为两部分，即主分片（primary shard）和副本分片（replica shard）。主数据作为权威数据，写过程中先写主分片，成功后再写副分片，恢复阶段以主分片为准。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

那索引与分片之间又有什么关系呢？

一个Elasticsearch索引包含了很多个分片，每个分片又是一个Lucene的索引，它本身就是一个完整的搜索引擎，可以独立执行建立索引和搜索任务。Lucene索引又由很多分段组成，每个分段都是一个倒排索引。Elasticsearch每次refresh都会生成一个新的分段，其中包含若干文档的数据。在每个分段内部，文档的不同字段被单独建立索引。每个字段的值由若干词（Term）组成，Term是原文本内容经过分词器处理和语言处理后的最终结果。

选举

在主节点选举算法的选择上，基本原则是不重复造轮子。最好实现一个众所周知的算法，这样的好处是其中的优点和缺陷是已知的。Elasticsearch的选举算法的选择上主要考虑下面两种。

• Bully算法：Leader选举的基本算法之一。它假定所有节点都有一个唯一的ID，使用该ID对节点进行排序。任何时候的当前Leader都是参与集群的最高ID节点。该算法的优点是易于实现。但是，当拥有最大ID的节点处于不稳定状态的场景下会有问题。例如，Master负载过重而假死，集群拥有第二大ID的节点被选为新主，这时原来的Master恢复，再次被选为新主，然后又假死……
• Paxos算法：Paxos非常强大，尤其在什么时机，以及如何进行选举方面的灵活性比简单的Bully算法有很大的优势，因为在现实生活中，存在比网络连接异常更多的故障模式。但Paxos实现起来非常复杂。

Elasticsearch的选主算法是基于Bully算法的改进，主要思路是对节点ID排序，取ID值最大的节点作为Master，每个节点都运行这个流程。同时，为了解决Bully算法的缺陷，其通过推迟选举，直到当前的Master失效来解决上述问题，只要当前主节点不挂掉，就不重新选主。但是容易产生脑裂（双主），为此，再通过法定得票人数过半解决脑裂问题。

Elasticsearch对Bully附加的三个约定条件

1. 参选人数需要过半。当达到多数时就选出临时主节点，为什么是临时的？每个节点运行排序取最大值的算法，结果不一定相同。举个例子，集群有5台主机，节点ID分别是1、2、3、4、5。当产生网络分区或节点启动速度差异较大时，节点1看到的节点列表是1、2、3、4，选出4；节点2看到的节点列表是2、3、4、5，选出5。结果就不一致了，由此产生下面的第二条限制。
2. 得票数需要过半。某节点被选为主节点，必须判断加入它的节点数达到半数以上，才确认Master身份（推迟选举）。
3. 当探测到节点离开事件时，必须判断当前节点数是否过半。如果达不到半数以上，则放弃Master身份，重新加入集群。如果不这么做，则设想以下情况：假设5台机器组成的集群产生网络分区，2台一组，3台一组，产生分区前，Master位于2台中的一个，此时3台一组的节点会重新并成功选取Master，产生双主，俗称脑裂。（节点失效检测）

流程如下图

节点失效检测会监控节点是否离线，然后处理其中的异常。失效检测是选主流程之后不可或缺的步骤，不执行失效检测可能会产生脑裂（双主或多主）。在此我们需要启动两种失效探测器：

• 在Master节点，启动NodesFaultDetection，简称NodesFD。定期探测加入集群的节点是否活跃。
• 非Master节点启动MasterFaultDetection，简称MasterFD。定期探测Master节点是否活跃。

分片内部原理

索引不变性

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。

倒排索引被写入磁盘后是不可改变的，索引的不变性具有以下好处：

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里。由于其不变性，只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 缓存(像过滤器缓存)在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

当然，一个不变的索引也有不好的地方。最大的缺点就是它是不可变的，我们无法对其进行修改。如果我们需要让一个新的文档可被搜索，就需要重建整个索引。这不仅对一个索引所能包含的数据量造成了巨大的限制，而且对索引可被更新的频率同样造成了影响。

动态更新索引

那么我们如何能在保留不变性的前提下实现倒排索引的动态更新呢？

答案就是使用更多的索引，即新增内容并写到一个新的倒排索引中，查询时，每个倒排索引都被轮流查询，查询完再对结果进行合并。

Elasticsearch基于Lucene引入了按段写入的概念——每次内存缓冲的数据被写入文件时，会产生一个新的Lucene段，每个段都是一个倒排索引。同时，在提交点中描述了当前Lucene索引都含有哪些分段。

按段写入的流程如下：

1. 新文档被收集到内存的索引中缓存
2. 当缓存堆积到一定规模时，就会进行提交
   • 一个新的段（倒排索引）被写入磁盘。
   • 一个新的提交点被写入磁盘。
   • 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件。
3. 新的段被开启，让它包含的文档可见以被搜索
4. 内存缓存被清空，等待接收新的文档

当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添加到索引。

那插入和更新又如何实现呢？

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

• 当一个文档被删除时，它实际上只是在 .del 文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
• 当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

近实时搜索

Elasticsearch和磁盘之间是文件系统缓存，在执行写操作时，为了降低从索引到可被搜索的延迟，一般新段会被先写入到文件系统缓存，再将这些数据写入硬盘（磁盘I/O是性能瓶颈）。

在写操作中，一般会先在内存中缓冲一段数据，再将这些数据写入硬盘，每次写入硬盘的这批数据称为一个分段。如同任何写操作一样，通过操作系统的write接口写到磁盘的数据会先到达系统缓存（内存）。write函数返回成功时，数据未必被刷到磁盘。通过手工调用flush，或者操作系统通过一定策略将文件系统缓存刷到磁盘。

这种策略大幅提升了写入效率。从write函数返回成功开始，无论数据有没有被刷到磁盘，只要文件已经在缓存中， 就可以像其它文件一样被打开和读取了。

Lucene允许新段被写入和打开——使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

Elasticsearch中将写入和打开一个新段的过程叫做refresh(刷新) 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说Elasticsearch是近实时搜索——文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

事务日志

由于系统先缓冲一段数据才写，且新段不会立即刷入磁盘，这两个过程中如果出现某些意外情况（如主机断电），则会存在丢失数据的风险。

为了解决这个问题，Elasticsearch增加了一个translog（事务日志），在每一次对Elasticsearch进行操作时均进行了日志记录，当Elasticsearch启动的时候，重放translog中所有在最后一次提交后发生的变更操作。

其执行流程如下：

1. 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了translog
   • 新的文档被添加到内存缓冲区并且被追加到了事务日志，如下图
     
2. 分片会每秒自动执行一次刷新，这些内存缓冲区的文档被写入新的段中并打开以便搜索，同时清空内存缓冲区。
   • 刷新完成后, 缓存被清空但是事务日志不会，同时新段写入文件系统缓冲区
     
3. 这个进程继续工作，更多的文档被添加到内存缓冲区和追加到translog
   • 事务日志不断积累文档
     
4. 当translog足够大时，就会执行全量提交，对文件系统缓存执行flush，将其内容全部写入硬盘中，并清空事务日志。
   • 在刷新（flush）之后，段被全量提交，并且事务日志被清空
     

除此之外，translog还有下面这些功能

• translog提供所有还没有被刷到磁盘的操作的一个持久化纪录。当Elasticsearch启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放translog中所有在最后一次提交后发生的变更操作。
• translog也被用来提供实时CRUD 。当你试着通过ID查询、更新、删除一个文档，在从相应的段中检索之前， 首先检查translog任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段，所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题，其会选择大小相似的分段进行合并。在合并过程中，标记为删除（更新）的数据不会写入新分段，当合并过程结束，旧的分段数据被删除，标记删除的数据才从磁盘删除。

流程如下图

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

整体写入流程如下图