共计 4719 个字符，预计需要花费 12 分钟才能阅读完成。
1. 节点
节点依照职责能够分为 master 节点 、 数据节点 和 协调节点，每个节点类型能够进行独自配置。默认状况下，集群不会对节点角色进行划分，所有节点都是平等的，能够负责所有的职责。然而在生产环境中须要对这些节点的角色进行最优划分，否则在高并发申请的状况下，集群容易呈现服务阻塞超时甚至服务解体的隐患。
1. master 节点
负责保护整个集群的相干工作，治理集群的变更，如创立 / 删除索引、节点衰弱状态监测、节点上 / 下线等。
master 节点是由集群节点通过 选举 算法选举进去的，一个集群中只有一个节点能够成为 master 节点，然而能够有一个或多个节点参加 master 节点的选举。在默认状况下，任意节点都能够作为 master 的候选节点，能够通过配置项 node.master 对以后节点是否作为 master 的候选节点进行管制。
为了防止选举时产生脑裂，倡议 master 的候选节点数量是 2n+1。
2. 数据节点
次要负责索引数据的保留工作，此外也执行数据的其余操作，如文档的删除、批改和查问操作。
数据节点的很多工作是调用 Lucene 库进行 Lucene 索引操作，因而这种节点对于内存和 I / O 的耗费比拟大，生产环境中应多留神数据节点的计算机负载状况。
3. 协调节点
客户端能够向 ES 集群的节点发动申请，这个节点叫作协调节点。
在默认状况下，协调节点能够是集群中的任意节点，此时它的生命周期是和一个独自的申请相干的。也就是说，当客户端向集群中的某个节点发动申请时，此时该节点被称为以后申请的协调节点；当它将响应后果返回给客户端后，该协调节点的生命周期就完结了。
当然，为了升高集群的负载，能够设置某些节点作为独自的协调节点。在节点的配置文件中设置 node.master 和 node.data 配置项为 false，此时，这个节点就不会被选中为 master 节点并且不再负责数据节点，而客户端就能够把这类节点作为协调节点来应用，把所有的申请都散发到这些节点上。
2. 分片
一个分片 (shard) 是一个最小级别“工作单元(worker unit)”，它只是保留了索引中所有数据的一部分。
分片能够是 主分片 (primary shard) 或者是 复制分片(replica shard)（或副分片）。
比方，一个具备 10 亿文档的索引占据 1TB 的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点解决搜寻申请，响应太慢。为了解决这个问题，ES 提供了将索引划分成多份的能力，这些份就叫做 分片。当你创立一个索引的时候，你能够指定你想要的分片的数量。每个分片自身也是一个功能完善并且独立的“索引”，这个“索引”能够被搁置到集群中的任何节点上。分片很重要，次要有两方面的起因：
- 容许你程度宰割 / 扩大你的内容容量。
- 容许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而进步性能 / 吞吐量。
至于一个分片怎么散布，它的文档怎么聚合回搜寻申请，是齐全由 ES 治理的，对于作为用户的你来说，这些都是通明的。
分片还有 正本 replica shard，在一个网络 / 云的环境里，失败随时都可能产生，在某个分片 / 节点不知怎么的就处于离线状态，或者因为任何起因隐没了，这种状况下，有一个故障转移机制是十分有用并且是强烈推荐的。为此目标，ES 容许你创立分片的一份或多份拷贝，这些拷贝叫做 复制分片，或者间接叫复制。
2.1. 主分片与副分片
1. 是否前期可批改
- 主分片数量，在创立索引时指定。创立索引后不能批改。
- 副分片数量，在创立索引后，仍然能批改。
因为数据存储时，会拿 hash 值，依据索引中主分片数量取余，定位所在分片的地址。如果后续批改了主分片数量，会导致数据的地址谬误。
2. 数量
- 主分片：默认数量为 5，单个分片的大小倡议在 20G～50G。主分片的数量决定了索引最多能存储多少数据（理论的数量取决于数据、硬件和利用场景）。
- 副分片：默认数量为 1。副分片的数量保证数据的高可靠性，避免数据失落。
每个主分片都有一个或多个正本分片，当主分片异样时，正本能够提供数据的查问等操作。
主分片和对应的正本分片是不会在同一个节点上的，所以正本分片数的最大值是 n -1（其中 n 为节点数）。
3. 意义
- 主分片：可程度宰割 / 扩大的内容容量；可在分片之上进行分布式的、并行的操作，进而提供性能 / 吞吐量。
- 副分片：在分片 / 节点失败的状况下，提供了高可用性。（留神：正本不能与对应的主分片置于同一节点上）；扩大搜寻量 / 吞吐量，因为搜寻能够在所有的正本上并行运行。
4. 副分片选举生成主分片
es 为了更好地稳定性和容灾，除了进行必要的索引备份外，正本的增加能够更好地维持集群数据完整性。
当呈现某个节点从集群脱离，在集群其余节点的正本，此时会选举出主分片，所以这里就有主分片和正本之间的数据同步问题。
5. 主从复制
当有数据写入时，申请节点收到申请，先转给主分片所在节点上执行申请，如果胜利，它转发申请到相应的几个复制分片所在的节点上。当所有的复制分片报告胜利，主分片所在节点报告胜利到申请的节点，申请的节点再报告给客户端。
6. 增减节点时，分片主动负载平衡
假如有 6 台机器总共 7 个分片, 必定就会有 1 台机器有 2 个分片, 此时给 es 集群新增 1 台机器进来, 那么有 2 个分片的那台机器会主动给 1 个分片调配给新退出的机器下来.
2.2. 集群状态
ES 的集群监控信息中蕴含了许多的统计数据，其中最为重要的一项就是集群衰弱。集群衰弱存储在 status 字段中，次要包含 green、yellow、red 三种状态。它的三种色彩含意如下：
green: 所有的主分片和正本分片都失常运行。yellow: 所有的主分片都失常运行，但不是所有的正本分片都失常运行。red: 有主分片没能失常运行。
3. 索引
3.1. 倒排索引
1. 正排索引
在说倒排索引之前咱们先说说什么是正排索引。
正排索引也称为 ” 前向索引 ”，它是创立倒排索引的根底。这种组织办法在建设索引的时候构造比较简单，建设比拟不便且易于保护; 因为索引是基于文档建设的，若是有新的文档退出，间接为该文档建设一个新的索引块，挂接在原来索引文件的前面。若是有文档删除，则间接找到该文档号文档对应的索引信息，将其间接删除。
他适宜依据文档 ID 来查问对应的内容。然而在查问一个 keyword 在哪些文档里蕴含的时候需对所有的文档进行扫描以确保没有脱漏，这样就使得检索工夫大大缩短，检索效率低下。
| 文档 ID | 文档内容 |
|---|---|
| 1 | elasticsearch 是最风行的搜索引擎 |
| 2 | php 是世界上最好的语言 |
| 3 | 搜索引擎是如何诞生的 |
只能在一起简略的场景下应用，如果通过 keyword 来挨个检索，性能太低。
2. 倒排索引
依据字面意思能够晓得他和正序索引是反的。在搜索引擎中每个文件都对应一个文件 ID，文件内容被示意为一系列关键词的汇合。例如“文档 1”通过分词，提取了 3 个关键词，每个关键词都会记录它所在在文档中的呈现频率及呈现地位。
那么下面的文档及内容构建的倒排索引后果会如下：
| 单词 | 文档 ID 列表 |
|---|---|
| elasticsearch | 1 |
| 风行 | 1 |
| 搜索引擎 | 1,3 |
| php | 2 |
| 世界 | 2 |
| 最好 | 2 |
| 语言 | 2 |
| 如何 | 3 |
| 诞生 | 3 |
比方咱们要查问‘搜索引擎’这个关键词在哪些文档中呈现过。
- 首先，咱们通过 倒排索引 能够查问到，该关键词呈现的文档地位是在 1 和 3 中;
- 而后，再通过 正排索引 查问到文档 1 和 3 的内容，并返回后果。
3.2. 索引不可变
ES 的搜寻高效的起因并不是像 Redis 那样重依赖内存的，而是通过建设非凡的索引数据结构 – 倒排索引实现的。倒排索引能够说是 ES 搜寻高效和反对非结构化数据检索的次要起因了，然而 倒排索引被写入磁盘后是不可扭转的，它永远不会批改。
写入磁盘的倒排索引是不可变的，劣势次要体现在：
- 不须要锁。因为如果从来不须要更新一个索引，就不用放心多个程序同时尝试批改，也就不须要锁。
- 一旦索引被读入内核的文件系统缓存，便会留在哪里，因为其不变性，只有文件系统缓存中还有足够的空间，那么大部分读申请会间接申请内存，而不会命中磁盘。这提供了很大的性能晋升。
- 其它缓存(像 filter 缓存)，在索引的生命周期内始终无效。它们不须要在每次数据扭转时被重建，因为数据不会变动。
- 写入单个大的倒排索引，能够压缩数据，较少磁盘 IO 和须要缓存索引的内存大小。
当然，不可变的索引有它的毛病：
- 当对旧数据进行删除时，旧数据不会马上被删除，而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时能力被移除，这样会造成大量的空间节约。
- 若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间节约。
- 每次新增数据时都须要新增一个段来存储数据。当段的数量太多时，对服务器的资源例如文件句柄的耗费会十分大。
- 在查问的后果中蕴含所有的后果集，须要排除被标记删除的旧数据，这减少了查问的累赘。
总体来看，倒排索引是拿空间换工夫。就义了空间资源，谋求更高的性能。
3.3. 段
1. 段
段 的概念提出次要是因为：在晚期全文检索中为整个文档汇合建设了一个很大的倒排索引，并将其写入磁盘中。如果索引有更新，就须要从新全量创立一个索引来替换原来的索引。这种形式在数据量很大时效率很低，并且因为创立一次索引的老本很高，所以对数据的更新不能过于频繁，也就不能保障时效性。
而且在底层采纳了分段的存储模式，使它在读写时简直完全避免了锁的呈现，大大晋升了读写性能。（像 ConcurrentHashMap 的分段思维）。
2. 提交点
每一个段自身都是一个倒排索引，但索引在 Lucene 中除示意所有段的汇合外，还减少了 提交点 的概念。
为了晋升写的性能，Lucene 并没有每新增一条数据就减少一个段，而是采纳提早写的策略，每当有新增的数据时，就将其先写入内存中，而后批量写入磁盘中。若有一个段被写到硬盘，就会生成一个提交点，提交点：就是一个列出了所有已知段和记录所有提交后的段信息的文件。
3. 段合并
因为主动刷新流程每秒会创立一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会耗费文件句柄、内存和 cpu 运行周期。更重要的是，每个搜寻申请都必须轮流查看每个段；所以段越多，搜寻也就越慢。
Elasticsearch 通过在后盾进行段合并来解决这个问题。小的段被合并到大的段，而后这些大的段再被合并到更大的段。
4. 近实时搜寻
ES 是怎么做到近实时全文搜寻？
磁盘是瓶颈。提交一个新的段到磁盘须要 fsync 操作，确保段被物理地写入磁盘，即时电源生效也不会失落数据。然而 fsync 是低廉的，重大影响性能，当写数据量大的时候会造成 ES 进展卡死，查问也无奈做到疾速响应。
所以 fsync 不能在每个文档被索引的时就触发，须要一种更轻量级的形式使新的文档能够被搜寻，这象征移除 fsync。
为了晋升写的性能，ES 没有每新增一条数据就减少一个段到磁盘上，而是采纳 提早写 的策略。
每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存，当达到默认的工夫（1 秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存零碎上，稍后再被刷新到磁盘中并生成提交点。
这里的内存应用的是 ES 的 JVM 内存，而文件缓存零碎应用的是操作系统的内存。新的数据会持续的被写入内存，但内存中的数据并不是以段的模式存储的，因而不能提供检索性能。由内存刷新到文件缓存零碎的时候会生成了新的段，并将段关上以供搜寻应用，而不须要等到被刷新到磁盘。
在 Elasticsearch 中，这种写入和关上一个新段的轻量的过程叫做 refresh（即内存刷新到文件缓存零碎）。默认状况下每个分片会每秒主动刷新一次。这就是为什么说 Elasticsearch 是近实时的搜寻了：文档的改变不会立刻被搜寻，然而会在一秒内可见。