Cluster：集群，Es是一个可以横向扩展的检索引擎（部分时候当作存储数据库使用），一个Es集群由一个唯一的名字标识，默认为“elasticsearch”。在配置文件中指定相同的集群名，Es会将相同集群名的节点组成一个集群。
Node：节点，集群中的任意一个实例对象，是一个节点
Index：索引，存放相同类型数据的一个集合，索引有唯一的名字，相比于关系型数据库，可以理解为一个表（6.0.0废除type之后）
Shard：分片，物理存储单位，创建一个索引时可以指定分成多少个分片来存储。每个分片本身也是一个功能完善且独立的“索引”，可以被放置在集群的任意节点上。
Replication：副本，对数据的备份，主要针对分片进行备份，即分片的备份
Document：文档，具体存储的数据（json结构）
如上图，每个云朵代表一个Es集群Cluster，集群中由一个个的Es实例Node构成，每个Es实例中存放着一个个的彩色方块（Shard），同一个集群中相同颜色的方块（shard）构成一个索引（index）
实际上，索引是一个抽象的逻辑概念，使用时，我们面向的是索引（Index），只需要指定索引名即可。索引背后真正的实体是分片（Shard）。
同一集群中，同一索引（Index）可能由多个分片（Shard）组成，这些Shard会分布在不同的节点（Node）中；而副本（Replication）则可以理解为一种特殊的分片，实际上数据是在一个个的分片上的，而副本的主要职责是对分片进行备份，以满足Es的稳定性。当副本数设置为1时，则代表着每个分片都会有一个副本，且副本中的内容与分片一样，肩负数据备份以及维稳责任。
例如我们在2个节点的集群上创建一个名为user的索引和student索引，user索引设置2个分片1个副本，student索引设置1个分片1个副本；那么user索引的两个shard会各自得到一个副本，副本和shard的内容一致，且均匀的分布在两个节点上（Es会根据相应的策略来尽可能保证分片和相应的副本不在同一节点中，且保证每个节点的数据都是完整的）。这样如果当Node1节点崩坏，对于user索引的查询，会由节点2的 shard1和shard0的副本来承担，且shard1和shard0的副本的数据之和是一个完整user的数据（等同于shard0和shard1）。
所以对于es来说，分片（shard）才是数据真正的载体，每一个Shard本质上是一个Lucene的索引（Lucene Index）。
每个Lucene Index(Es的Shard) 是由多个Segment构成 ，Segement才是Lucene和Es查询性能的核心，Segment主要承载三部分内容：
Inverted Index
Stored Fields
Document Values
Segment中最重要的就是倒排索引，也是Es能够快速检索的根本，它是Segment基于存储的数据抽离出来的一个能够快速检索的数据结构，一个倒排索引的结构主要由一个有序的数据字典Dictionary（包括单词Term和它出现的频率）和 单词Term对应的Postings（文档的id或位置）组成：
对于倒排索引，Es中是根据字段不同类型进行不同的策略：
Text 字段：
Keyword 字段：
Numeric 字段（如 integer, float, double 等）：
Date 字段：
Boolean 字段 和 Binary 字段：
构建倒排索引主要根据文档字段的类型主要为text，构建倒排索引的过程是：
在Elasticsearch中，每个字段的倒排索引是独立的，这意味着对于每个字段，Elasticsearch都会维护一个单独的倒排表，该倒排表包含了该字段中词项的文档映射信息。
在索引文档时，Es是会保存原始内容的，原始文档内容在Es中表现为JSON， 而使用Es时，多是基于一个JSON中的某几个字段进行检索，大部分情况是不需要原始JSON内容的，但是若无特殊指定，Es每次检索是需要把完整的JSON在查询结果中通过_source进行携带：
{ "_index": "ariticle", "_type": "_doc", "_id": "1", "_version": 1, "_seq_no": 0, "_primary_term": 1, "found": true, "_source": { //不进行查询指定，默认所有字段通过_source返回 "user": "张三", "title": "这是一个示例文章", "context": "这是文章中的上下文以及具体的文章内容XXX" } }
大批量的字段返回，除造成了额外的网络传输消耗外，在Es内部，也需要对整个文档进行序列化，造成资源浪费。
Stored Fields（存储字段）是一种特殊的字段类型，可以在文档中指定多个字段并将字段的原始内容进行额外存储，形成一个和_source平级的内容，检索时不需要序列化整个文档，直接读取额外的存储空间内容即可。
使用方法是在设计索引mapping时通过store属性进行字段指定。
使用 store Fields后，可将指定的字段额外被Segment存储一份，检索时直接读取
//在索引创建时就固定常用哪些字段 { "ariticle": { "aliases": { }, "mappings": { "_doc": { "properties": { "title": { //默认没有store属性,默认值就是false "type": "text", }, "context": { //默认没有store属性,默认值就是false "type": "text" }, "user": { //明确指定store属性为true "type": "keyword", "store": true } } } } } //同样的查询 { "query": { "match_all": {} }, "from":0, "size":10 } //返回结果 { "_index": "ariticle", "_type": "_doc", "_id": "1", "_version": 1, "found": true, "fields": { //此时多了名称为fields的字段，并且没有了_source "user": [ //user的stroe属性设置为true，因此显示在结果中 "张三" ] } }
事实上不论设不设置store属性为true，Elasticsearch都是会把原始文档进行存储的，当store为false时(默认配置），这些field只存储在"_source" field中，我们进行检索时，通过DSL来控制_source中返回的字段原文内容；但是当使用了store Fields时，会对相应字段的内容多存储一份，检索时针对使用了store Fields的字段，不需要序列化整个文档，相比通过指定返回字段查询效率会快很多，代价就是需要额外的存储一份内容，且内容在定义时就固定，不如在DSL中使用 _source 指定内容灵活。
Document Values主要用于 排序、聚合、脚本索引中，Document Values对数据内容进行列式存储，便于快速进行 sort、aggs操作；
这里Docvalus是相当于倒排索引的正排索引，它作用于除Text类型之外的类型字段，倒排索引的优势 在于查找包含某个项的文档，而对于从另外一个方向的相反操作并不高效，即：确定哪些项是否存在单个文档里。这种场景下，就需要类似Mysql那种列式存储，构建一个正排索引
Doc Terms ----------------------------------------------------------------- Doc_1 | brown, dog, fox, jumped, lazy, over, quick, the Doc_2 | brown, dogs, foxes, in, lazy, leap, over, quick, summer Doc_3 | dog, dogs, fox, jumped, over, quick, the -----------------------------------------------------------------
DocValues是在索引时与倒排索引同时生成的，并且是不可变的，需要持久化到磁盘中。Doc values 是不支持对需要分词的字段进行列存储的（例如text），然而，这些字段仍然可以使用聚合，是因为使用了fielddata 的数据结构。与 doc values 不同，fielddata 构建和管理 100% 在内存中，常驻于 JVM 内存堆。
Fielddata默认是不启用的，因为text字段比较长，一般只做关键字分词和搜索，很少拿它来进行全文匹配和聚合还有排序，因为大多数这种情况是无意义的，一旦启用将会把text都加载到内存中，那将带来很大的内存压力，导致出现内存熔断现象（circuit breaker）。
它通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。如果估算查询大小超出限制，就会触发熔断，查询会被中止并返回异常。
fielddata的内存配置在elasticsearch.yml中
indices.breaker.fielddata.limit fielddata级别限制，默认为堆的60% indices.breaker.request.limit request级别请求限制，默认为堆的40% indices.breaker.total.limit 保证上面两者组合起来的限制，默认堆的70%
ElasticSearch在查询时涉及其自身JVM的缓存一共分为三类：
Node Query Cache：
indices.queries.cache.size: 控制查询缓存的内存大小，默认为节点堆内存的10%。indices.queries.cache.count: 控制缓存的总数量，默认值通常是10000。Shard Request Cache ：
size=0 的请求，以完整DSL为缓存键，不会缓存 hits，但会缓存 hits.total 以及聚合信息。refresh_interval，即在默认情况下每1秒钟失效一次。index.requests.cache.enable: 控制是否启用分片级别的缓存，默认为 true。indices.requests.cache.size: 控制请求缓存在JVM堆中的百分比，默认为1%。indices.requests.cache.expire: 配置缓存过期时间，单位为分钟。Fielddata Cache ：
text 类型或者没有为该字段设置 doc_values，对于该字段聚合、排序或者脚本访问时会缓存。Fielddata 加载到内存中，它会保留在那里，直到相关段被删除或更新。indices.fielddata.cache.size: 控制字段数据缓存的大小，默认不限制。indices.breaker.fielddata.limit: 设置 Fielddata 断路器限制大小，默认为60%的JVM堆内存。以上为查询时常用的缓存，多为Es本身JVM的内存进行划分和使用，另外Es在写入时还会使用一定的SystemCache，如Recycler Cache、Warmer Cache等。
一次新增文档（索引文档），在集群视角的流程：
文档数据被写入后，首先进入到Memory Buffer和TransLog中，此时shard中的Segment还是之前已经稳定的数据，新写入的文档还没有形成Segment，无法被Es查到。根据 index.refresh_interval 设置 的refresh （冲刷）间隔时间，数据开始进行refresh，Memory Buffer中的文档被内容分析、分词，形成一个新的Segment，然后Memory Buffer开始清空，refresh后新生成的Segment是暂存在FilesystemCache中的，所以从存储上看，新的文档从Memory Buffer 转移到了 Filesystem Cache，到此，新插入的文档数据才可以被Es查询到
随着TransLog越来越大，会触发Flush过程，在这个过程中，FilesystemCache中的内容会被写入到磁盘中，段的fsync将创建一个new commit point，此时清空Filesystem Cache，然后删除TransLog，再生成一个新的TransLog，记录后续的内容
由于refresh流程每次都会创建一个新的段，refresh的频繁会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。而且每个搜索请求都必须轮流检查每个段，所以段越多，搜索也就越慢。于是Es在后他就需要不定期的合并Segment，以减少Segment的数量。
合并进程选择一小部分大小相似的段，并且在后台将它们合并成为更大的段（过程中并不会中断索引和搜索）。合并后的新Segment被Flush到磁盘中，然后打开新的Segment的检索功能，同时删除磁盘上旧的Segment。
elasticSearch中的检索一般分为两类，一类是Get查询，即通过_id查询具体的文档，一类是Search查询，即向Es发起DSL语句的查询。这里主要以Search查询为例
客户端向Es服务（集群）发送指定索引的查询请求，请求先到达主节点（协调节点）
协调节点根据集群部署，将请求转发到其他节点所对应的索引分片上（优先使用主节点）
各个节点上的分片在其内部进行数据检索，检索出符合条件的数据
此过程中会根据查询，判定是否符合Shard Cache标准，进行Cache查询或缓存内容
涉及聚合或分析字段的聚合操作，内部Segment会判定是否fielddata Cache标准，并启用该缓存
各分片将检索出的数据发回主节点，主节点进行汇总后返回给客户端
也就是说，Es是通过分片将同一索引的数据均匀的散布在集群中，每个分片依赖所处节点设备的硬件资源进行独立查询，通过网络传输，将结果返回。
说Segment的查询之前补充一下上文Segment的内容部分（注意，在Es或者Lucene中提及的Segment是逻辑概念，不等价于磁盘上的段）；Segment的组成部分和文档数据在磁盘上的对应关系：
更多文档类型可以此处查看
请求来的shard内部，解析出DSL，转译为Lucene的语法
通过 commit point记录分发到segments中，此时的segment分为两种，一种是经过flush和merge的，我称之为磁盘版segment（当然不那么准确）；还有一种是处在索引过程中的，上文中存在于FilesystemCache中可被查询的，我称之为内存版segment。两者不同之处就在于，前者涉及磁盘IO读取部分数据来完成查询，后者不需要IO，直接内存进行查询
每个segment根据词法分析得出的词项，进行词典检索（词典的数据.tip文件一般加载在内存中，不需要磁盘IO，非常快），配合倒排表，快速找到相关文档（这个过程需要磁盘IO）
如果涉及数字类型的sum、max、min的聚合或者text的聚合操作，则segment会使用DocValues相关的文件，借助列式存储的优势快速运算；fielddata缓存机制也是在此时发挥作用。
segment完成检索后将内容返回到shard中（其他segment也是同理），由shard去进行合并、缓存等操作
由于商品变更MQ消息量巨大，为了提升更新ES的性能，防止出现MQ消息积压问题，所以本系统使用了BulkProcessor进行批量异步更新。