分布式安装 Elasticsearch
环境 windows
1、进入官网下载 Elasticsearch ： Elasticsearch-7.13.3
2、选择一个盘，新建目录 ES（可自行定义），将下载的文件放到 ES 目录中，并将文件解压后复制两份，分别自定义命令为：elasticsearch-node-master、elasticsearch-node-1、elasticsearch-node-2
解释：每一个文件夹就是 ES 集群的一个节点 node，标记为 master 将作为主节点
4、修改每个节点的配置文件
1）master节点的配置文件
C:ESelasticsearch-node-masterconfigelasticsearch.yml
2）node-1 节点的配置文件修改
C:ESelasticsearch-node-1configelasticsearch.yml
3）node-2 节点的配置文件修改
C:ESelasticsearch-node-2configelasticsearch.yml
5、启动 Elasticsearch
方法一：单独启动 ES
window环境下可以直接点击 bin 目录下的 elasticsearch.bat 文件；或者 cmd 命令窗口进入到 bin目录，执行以下命令
按照以上步骤分别开启 node-1 、node-2 两个节点
方法二：批量启动 ES 的方法
windows下如果为了测试，建立多个节点，可以 bat 一键即可同时启动多个 ES，步骤如下
在桌面建立 start.bat 文件，用 txt 打开文件，输入以下代码，保存后双击 start.bat 即可
6、检测 Elasticsearch 是否启动成功
浏览器输入以下地址
节点启动看到有这个标志则表示节点启动成功
浏览器验证
至此，Elasticsearch 集群部署完成。
问题：如何直观地查看集群是否真的有三个节点呢？
答案：安装 Elasticsearch-head 前端插件可查阅集群和节点信息
请看下一篇文章：windows 安装 Elasticsearch-head
安装 Elasticsearch-head 前端插件可查阅集群和节点信息
请看下一篇文章：windows 安装 Elasticsearch-head
ElasticSearch分页方案
"浅"分页是最简单的分页方案。es会根据查询条件在每一个DataNode分片中取出from+size条文档，然后在MasterNode中聚合、排序，再截取size-from的文档返回给调用方。当页数越靠后，也就是from+size越大，es需要读取的数据也就是越大，聚合和排序的时候处理的数据量也越大，此时会加大服务器CPU和内存的消耗。
其中，from定义了目标数据的偏移值，size定义当前返回的数目。默认from为0，size为10，即所有的查询默认仅仅返回前10条数据。
在这里有必要了解一下from/size的原理：
因为es是基于分片的，假设有5个分片，from=100，size=10。则会根据排序规则从5个分片中各取回100条数据数据，然后汇总成500条数据后选择最后面的10条数据。
做过测试，越往后的分页，执行的效率越低。总体上会随着from的增加，消耗时间也会增加。而且数据量越大，就越明显！
from+size查询在10000-50000条数据（1000到5000页）以内的时候还是可以的，但是如果数据过多的话，就会出现深分页问题。
为了解决上面的问题，elasticsearch提出了一个scroll滚动的方式。
scroll 类似于sql中的cursor，使用scroll，每次只能获取一页的内容，然后会返回一个scroll_id。根据返回的这个scroll_id可以不断地获取下一页的内容，所以scroll并不适用于有跳页的情景。
scroll=5m表示设置scroll_id保留5分钟可用。
使用scroll必须要将from设置为0。
size决定后面每次调用_search搜索返回的数量
然后我们可以通过数据返回的_scroll_id读取下一页内容，每次请求将会读取下10条数据，直到数据读取完毕或者scroll_id保留时间截止：
注意：请求的接口不再使用索引名了，而是 _search/scroll，其中GET和POST方法都可以使用。
scroll删除
根据官方文档的说法，scroll的搜索上下文会在scroll的保留时间截止后自动清除，但是我们知道scroll是非常消耗资源的，所以一个建议就是当不需要了scroll数据的时候，尽可能快的把scroll_id显式删除掉。
清除指定的scroll_id：
DELETE _search/scroll/DnF1ZXJ5VGhlbkZldGNo.....
清除所有的scroll：
DELETE _search/scroll/_all
scroll 的方式，官方的建议不用于实时的请求（一般用于数据导出），因为每一个 scroll_id 不仅会占用大量的资源，而且会生成历史快照，对于数据的变更不会反映到快照上。
search_after 分页的方式是根据上一页的最后一条数据来确定下一页的位置，同时在分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上。但是需要注意，因为每一页的数据依赖于上一页最后一条数据，所以无法跳页请求。
为了找到每一页最后一条数据，每个文档必须有一个全局唯一值，官方推荐使用 _uid 作为全局唯一值，其实使用业务层的 id 也可以。
使用search_after必须要设置from=0。
这里我使用timestamp和_id作为唯一值排序。
我们在返回的最后一条数据里拿到sort属性的值传入到search_after。
使用sort返回的值搜索下一页：
4：修改默认分页限制值10000
可以使用下面的方式来改变ES默认深度分页的index.max_result_window 最大窗口值
curl -XPUT -d '{ "index" : { "max_result_window" : 500000}}'
其中my_index为要修改的index名，500000为要调整的新的窗口数。将该窗口调整后，便可以解决无法获取到10000条后数据的问题。
注意事项
通过上述的方式解决了我们的问题，但也引入了另一个需要我们注意的问题，窗口值调大了后，虽然请求到分页的数据条数更多了，但它是用牺牲更多的服务器的内存、CPU资源来换取的。要考虑业务场景中过大的分页请求，是否会造成集群服务的OutOfMemory问题。
修改最大限制值之后确实可以使from+size查询到更后面页的数据，但是每次查询得到的总数量最大任然是10000，要想获取大于1万的查询数据量，可以分两步查询，第一步使用scroll查询获取总数据量；第二部使用from+size查询每页的数据，并设置分页。这样即解决了from+size无法查询10000之后的数据，也解决了scroll无法跳页的问题。
使用scroll可能遇到的问题：
Caused by: org.elasticsearch.ElasticsearchException: Trying to create too many scroll contexts. Must be less than or equal to: [500]. This limit can be set by changing the [search.max_open_scroll_context] setting.
这个报错是从es的日志文件中查出来的，大致意思是：尝试创建更多的scroll对象失败了，scroll对象总数量应该控制在500以内。可修改search.max_open_scroll_context的值来改变500这个阈值。
原因：通过scroll 深分页可知道，es服务端会在内存中生成一个scroll_id对象，并会为该值指定过期时间，翻页的时候使用scroll_id来获取下一页的数据。默认情况下，一个实例下面仅可以创建最多500个scroll上下文对象，也就是500个scroll_id。报此错误的原因就是创建scroll上下文对象失败，因为当前已经存在500个这样的对象了。
解决办法：
1：通过观察可以发现，即使不做任何的处理，过一会就又可以发起scroll请求了，这是因为时间超过了scroll生命周期时间，scroll对象自己死掉了一些。
2：按照提示说的，修改search.max_open_scroll_context的值
put http://{{es-host}}/_cluster/settings
{
}
[图片上传失败...(image-4dc354-1583253824871)]
3：在使用完scroll_id之后立即调用删除接口，删除该scroll对象
删除单个scroll
DELETE http://{{es-host}}/_search/scroll
{
}
删除所有scroll
delete http://{{es-host}}/_search/scroll/_all
配置Elasticsearch
Elasticsearch船只具有良好的默认值，并且只需要很少的配置。可以在运行的集群上使用集群更新设置API更改大多数设置。
配置文件应该包含特定于节点的设置(例如node.name和路径)，或者节点为了能够加入集群而需要的设置，例如 cluster.name 和 network.host 。
Elasticsearch有三个配置文件:
这些文件位于config目录中，其默认位置取决于安装是来自存档分发版(tar.gz或zip)还是包分发版(Debian或RPM包)。
对于存档发行版，config目录位置默认为 $ES_HOME/config 。配置目录的位置可以通过 ES_PATH_CONF 环境变量改变，如下所示:
或者，您可以通过命令行或shell配置文件导出ES_PATH_CONF环境变量。
对于包分发，配置目录位置默认为 /etc/elasticsearch 。配置目录的位置也可以通过 ES_PATH_CONF 环境变量更改，但是请注意，仅在shell中设置是不够的。相反，这个变量来源于 /etc/default/elasticsearch (用于Debian包)和 /etc/sysconfig/elasticsearch (用于RPM包)。您需要相应地在其中一个文件中编辑 ES_PATH_CONF=/etc/elasticsearch 条目，以更改配置目录的位置。
配置格式为YAML。下面是更改数据和日志目录路径的示例:
设置也可以扁平化如下:
在YAML中，你可以将非标量值格式化为序列:
虽然不太常见，但你也可以将非标量值格式化为数组:
使用${…}符号将被替换为环境变量的值。例如:
环境变量的值必须是简单字符串。使用逗号分隔的字符串来提供Elasticsearch将解析为列表的值。例如，Elasticsearch将以下字符串分割为 ${HOSTNAME} 环境变量的值列表
集群和节点设置可以根据配置方式进行分类:
您可以使用 集群更新设置API 在运行的集群上配置和更新动态设置。您还可以使用 elasticsearch.yml 在未启动或关闭的节点上本地配置动态设置。
使用集群更新设置API进行的更新可以是持久的(跨集群重启应用)，也可以是短暂的(在集群重启后重置)。您还可以通过使用API为临时或持久设置赋值为空来重置它们。
如果您使用多个方法配置相同的设置，Elasticsearch将按照以下优先顺序应用这些设置:
例如，您可以应用瞬变设置来覆盖持久设置或 elasticsearch.yml 设置。然而，对 elasticsearch.yml 的更改,不会覆盖已定义的瞬态或持久设置。
最好使用集群更新设置API设置动态的集群范围设置，并使用 elasticsearch.yml 仅用于本地配置。使用集群更新设置API可以确保所有节点上的设置是相同的。如果您不小心在 elasticsearch.yml 中配置了不同的设置。在不同的节点上，很难注意到差异。
静态设置只能在未启动或关闭的节点上使用 elasticsearch.yml 进行配置。
必须在集群中的每个相关节点上设置静态设置
Elasticsearch开始时只需要很少的配置，但是在生产环境中使用集群之前，有很多方面需要考虑:
Elasticsearch将创建索引的数据写入索引，将数据流写入数据目录。Elasticsearch将自己的应用程序日志(其中包含关于集群运行状况和操作的信息)写入日志目录
对于macOS .tar.gz、Linux .tar.gz和Windows .zip安装，数据和日志默认是 $ES_HOME 的子目录。但是，在升级过程中， $ES_HOME 中的文件有被删除的风险
In production, we strongly recommend you set the path.data and path.logs in elasticsearch.yml to locations outside of $ES_HOME . Docker , Debian , RPM , macOS Homebrew , and Windows .msi installations write data and log to locations outside of $ES_HOME by default.
To avoid errors, only Elasticsearch should open files in the path.data directory. Exclude the path.data directory from other services that may open and lock its files, such as antivirus or backup programs.
Supported path.data and path.logs values vary by platform
只有当一个节点与集群中的所有其他节点共享 cluster.name 时，该节点才能加入集群。默认名称是 elasticsearch ，但是您应该将其更改为描述集群用途的适当名称。
不要在不同的环境中重用相同的集群名称。否则，节点可能会加入错误的集群
Elasticsearch使用 node.name 作为Elasticsearch特定实例的人类可读标识符。这个名称包含在许多api的响应中。当Elasticsearch启动时，节点名默认为机器的主机名，但是可以在 elasticsearch.yml 中显式配置
缺省情况下，Elasticsearch只绑定到 127.0.0.1 和 [::1] 等环回地址。这对于在单个服务器上运行一个或多个节点的集群进行开发和测试已经足够了，但是 弹性生产集群 必须包含其他服务器上的节点。有许多 网络设置 ，但通常你只需要配置 network.host :
当你为 network.host 提供值时。Elasticsearch假定您正在从开发模式转向生产模式，并将一些系统启动检查从警告升级到异常。看看 开发和生产模式 之间的区别。
在投入生产之前，配置两个重要的发现和集群形成设置，以便集群中的节点能够相互发现并选择一个主节点。
Elasticsearch可以开箱即用，无需任何网络配置，它将绑定到可用的环回地址，并扫描本地端口 9300 到 9305 ，以便与运行在同一服务器上的其他节点连接。这种行为提供了一种无需进行任何配置的自动集群体验。
当您希望与其他主机上的节点形成集群时，使用 静态 discovery.seed_hosts 设置. This setting provides a list of other nodes in the cluster that are master-eligible and likely to be live and contactable to seed the discovery process .
此设置接受集群中所有符合主节点的地址的YAML序列或数组。每个地址可以是一个IP地址，也可以是通过DNS解析为一个或多个IP地址的主机名。
当您第一次启动Elasticsearch集群时， 集群引导 步骤将确定在第一次选举中计票的符合主资格的节点集。在 开发模式 下，如果没有配置发现设置，这个步骤将由节点自己自动执行。
因为自动引导 本身就不安全 ,，所以在生产模式下启动新集群时，必须显式列出符合主资格的节点，这些节点的投票应该在第一次选举中计算。您可以使用集群设置此列表。 initial_master_nodes 设置。
在集群第一次成功形成之后，删除每个节点配置中的 Initial_master_nodes 设置。在重新启动集群或向现有集群添加新节点时，不要使用此设置。
通过节点的 node.name 标识初始主节点, 该节点默认为主节点的主机名。请确保 cluster.initial_master_nodes 值 与 node.name 完全匹配如果您使用完全限定的域名(FQDN)，例如master-node-a.example.com作为您的节点名，那么您必须在此列表中使用FQDN。相反，如果node.name是没有任何尾随限定符的裸主机名，您也必须省cluster.initial_master_nodes中的尾随限定符如果您使用完全限定的域名(FQDN)，例如 master-node-a.example.com 作为您的节点名, 那么您必须在此列表中使用FQDN。相反，如果f node.name 是没有任何尾随限定符的裸主机名，您也必须省略 cluster.initial_master_nodes 中的尾随限定符。
请参见 bootstrapping a cluster 以及 发现和集群形成设置 .
默认情况下，Elasticsearch会根据节点的 角色 和总内存自动设置JVM堆大小。对于大多数生产环境，我们建议使用默认大小。
自动堆大小需要 bundled JDK ，如果使用自定义JRE位置，则需要Java 14或更高版本的JRE。
如果需要，您可以通过手动 设置JVM堆大小 来覆盖默认大小
默认情况下，Elasticsearch将JVM配置为将堆内存溢出异常转储到默认数据目录。在RPM和Debian软件包中，数据目录是/var/lib/elasticsearch。在Linux、MacOS和Windows发行版上，数据目录位于Elasticsearch安装的根目录下。
如果此路径不适合接收堆转储，请修改 -XX:HeapDumpPath=… jvm.options
默认情况下，Elasticsearch启用垃圾收集(GC)日志。这些是在jvm中配置的 jvm.options 并输出到与Elasticsearch日志相同的默认位置。默认配置每64mb轮换一次日志，最多可以消耗2gb的磁盘空间。
您可以使用 JEP 158: Unified JVM Logging 中描述的命令行选项重新配置JVM日志。除非您更改了默认jvm。选项文件，Elasticsearch默认配置将应用于您自己的设置之外。要禁用默认配置，首先通过提供 -Xlog:disable 选项禁用日志记录，然后提供您自己的命令行选项。这将禁用所有JVM日志记录，因此一定要检查可用选项并启用所需的所有内容。
要查看原始JEP中未包含的其他选项，请参见使用 JVM统一日志框架启用日志记录 .
Change the default GC log output location to /opt/my-app/gc.log by creating $ES_HOME/config/jvm.options.d/gc.options with some sample options:
Configure an Elasticsearch Docker container to send GC debug logs to standard error ( stderr ). This lets the container orchestrator handle the output. If using the ES_JAVA_OPTS environment variable, specify:
默认情况下，Elasticsearch使用启动脚本直接在系统临时目录下创建的私有临时目录。
在某些Linux发行版上，如果最近没有访问过/tmp中的文件和目录，系统实用程序将清除它们。如果需要临时目录的特性长时间不使用，那么在Elasticsearch运行时，这种行为会导致私有临时目录被删除。如果随后使用需要此目录的特性，则删除私有临时目录会导致问题。
如果您使用.deb或.rpm包安装Elasticsearch，并在systemd下运行它，那么Elasticsearch使用的私有临时目录将被排除在定期清理之外。
如果您打算在Linux或MacOS上长时间运行.tar.gz发行版，请考虑为Elasticsearch创建一个专用的临时目录，该目录不在将旧文件和目录清除的路径下。这个目录应该设置权限，以便只有作为Elasticsearch运行的用户才能访问它。然后，在启动Elasticsearch之前，设置$ES_TMPDIR环境变量指向这个目录。
默认情况下，Elasticsearch将JVM配置为将致命错误日志写入默认日志目录。对于 RPM 和 Debian 软件包, 这个目录是 /var/log/elasticsearch . On Linux and MacOS and Windows 发行版, logs 目录位于Elasticsearch安装根目录下。
这些日志是JVM遇到致命错误(例如分段错误)时产生的。如果此路径不适合接收日志，请修改 -XX:ErrorFile=... 在 jvm.options 条目。
在灾难中，快照可以防止数据永久丢失。快照生命周期管理是对集群进行定期备份的最简单方法。有关更多信息，请参见备份集群。
在灾难中, 快照 可以防止数据永久丢失. 快照生命周期管理 是对集群进行定期备份的最简单方法. 有关更多信息, 请参见 备份集群 。
备份集群的唯一可靠和受支持的方法是使用快照。您不能通过复制Elasticsearch集群节点的数据目录来备份该集群。不支持从文件系统级备份恢复任何数据的方法。如果试图从这样的备份恢复集群，可能会出现损坏、丢失文件或其他数据不一致的报告，或者看起来已经成功地悄无声息地丢失了一些数据。
有些设置是敏感的，仅依靠文件系统权限来保护它们的值是不够的。对于这个用例，Elasticsearch提供了一个密钥存储库和 elasticsearch -keystore 工具 来管理密钥存储库中的设置。
只有重新启动Elasticsearch后，对keystore的所有修改才会生效。
这些设置就像elasticsearch中的常规设置一样。Yml配置文件，需要在集群中的每个节点上指定。目前，所有安全设置都是特定于节点的设置，在每个节点上必须具有相同的值。
Just like the settings values in elasticsearch.yml , 对密钥存储库内容的更改不会自动应用到运行的Elasticsearch节点。重新读取设置需要重新启动节点。但是，某些安全设置被标记为 可重新加载 。. Such settings can be re-read and applied on a running node .
所有安全设置的值(无论是否可重新加载)必须在所有集群节点上相同。在进行所需的安全设置更改后，使用 bin/elasticsearch-keystore add 命令, call:
keystore-password : 用于加密Elasticsearch密钥库的密码
此API在每个集群节点上解密并重新读取整个密钥存储库，但只应用可重新加载的安全设置。对其他设置的更改直到下次重启才会生效。一旦调用返回，重新加载就完成了，这意味着依赖于这些设置的所有内部数据结构都已更改。所有的设置都应该从一开始就具有新值。
当更改多个可重新加载的安全设置时，在每个集群节点上修改所有安全设置，然后发出 reload_secure_settings 调用，而不是在每次修改后重新加载。
有可重新加载的安全设置:
ElasticSearch索引的创建
最简单的创建一个索引的方法就是：
索引名称有以下限制：
需要注意，官方文档中描述， "setting" 内部实际上还有一层 "index" 正常情况下是省略的，实际上，在kibana的dev tools里面的默认提示是不提示有"index"这个选择的。不过，如果手动输入的话，实际上也是能够执行成功的。
在创建时，可以设定默认的分片数和备份数，这里分片数据设置为2，备份数设置为1，由于我后台设置的是一个三节点集群，因此现在集群是可以创建成功的。
查看节点的分布:
索引的分片数一旦指定就不能更改。虽然索引提供了 shrink 和 split API提供修改分片的能力，但是这种能力实际上也是创建了一个新的索引替换了原有的索引。
这里，我把 dynamic 打开，这样没有预习定义的属性也可以插入进来。事实上，这个参数默认就是 true 。
在创建索引时，可以增加下面这一段，为索引设置别名。
另外，如果索引已经存在，同样也可以给其加上索引。
索引的操作包括 add 和 delete ，可以给一个索引添加别名或者将一个索引的别名去除。
另外，索引还支持 filter 操作，其作用相当于是给索引制作了一个视图，对查询的结果做过滤。比如上面，我给alias_aaa设置了过滤条件。早做搜索时，只会呈现 cpu=intel 的结果。
此外，别名设置是也可以设置 routing 值，并且可以分别为搜索和索引设置。
最后，别名提供了设置 is_write_index 的功能，其作用在于，当别名执行不止一个索引的情况下，发生写操作时决定向哪个索引写入。
这一能力再索引生命周期管理模块中有重要的作用。参考：
使用索引生命周期管理模块时，可以在 hot 阶段做rotate，这时候需要指定，这一系列索引中，需要往哪个索引中写。
当一个别名执行多个索引，并且没有设定写指针时，写入操作会失败：
索引创建后，其部分属性是可以修改的。
可以通过将相关值设为null的方法恢复设置的默认值。
我们成功地创建了索引。
Elasticsearch的几种查询方式及其参数说明
查询方式：
1、query string search
1.1 GET /索引/类型/_search
其中：
took：耗费时间
timed_out: 是否超时
_shards：数据分片信息
totle：被查询的分片数
successful：成功执行查询的分片数
failed：失败执行查询的分片数
hits.total：查询结果的数量
hits.max_score：对于查询条件的匹配度，分数越高越匹配
hits.hits：所有匹配到的数据
"_index"：所在索引
"_type"：对应的类型
"_id"：主键ID
"_score"：匹配分数
"_source"：数据资源
1.2 GET /索引/类型/_search?q=field:xxxsort=field:desc
查询语句说明：
q代表查询条件，q等于键值对
sort代表排序，field代表字段，desc代表排序方式
2 query DSL（Domain Specified Language）
2.1 GET /索引/类型/_search
{
"query": { // 查询条件
"match":{ // 改为match_all 查全部
"field": "XXX"
}
},
“_source”: [ "field1", "field2" ], // 指定结果列
"hightlight": { // 查询结果高亮显示
"pre_tags" : "p class='red'", // 自定义高亮标签开始
"post_tags" : "/p", // 自定义高亮标签结尾
"fields": { // 要高亮显示的字段
"field": {} // 实际字段
}
},
"sort": [ // 排序条件
{"parice": "desc"}
],
“form”: 1, // 第几页
"size": 2 // 每页几天
}
3 query filter
GET /索引/类型/_search
{
“bool”: {
"must": { // 必须匹配
"match": {
"field": "XXX"
}
},
"filter": { // 筛选
"range": { // 范围
"field": { "gt": "22" } // gt代表大于
}
}
}
}
4 full-text search 全文检索
GET /索引/类型/_search
{
“query”: {
"match": { "field": "XXX OOOO" } // 查询匹配全文中的field字段，包含OOOO和XXX的数据信息，其中包含XXX OOOO的数据的_score分数最高，匹配度最高，原理为，数据进入时会将field字段的内容进行分词，然后根据分出来的每个词去匹配
}
}
5 phrase search （短语搜索）
GET /索引/类型/_search
{
“query”: {
"macth_phrase" : { // 只匹配XXX OOOO这个短句，而全文检索是除此之外，还会将包含XXX和包含OOOO的也都匹配出来
"field": "XXX OOOO"
}
}
}
Elasticsearch源码分析-索引分析(一)
首先，我们来看一个索引请求：
这个请求的主要作用是向item索引中添加一个索引文档，文档信息：
文档 id: 28589790
字段id: 28589790
字段text: 这是一个索引文本
如果索引中已经包含id为28589790的索引，elasticsearch将会使用这条数据进行覆盖
elasticsearch使用HttpRequestHandler.messageReceived()方法接受用户请求，然后调用dispatchRequest()方法对请求进行转发。
当请求跳转到RestController时，会调用getHandler()方法根据请求的Path获取对应的handler，由上文可以看出 item/show/28589790 会匹配到RestIndexAction
handler.handleRequest()方法最终会调用RestIndexAction.handleRequest()方法对索引参数进行解析，创建索引请求对象indexRequest，然后调用client.index()开始创建索引
在索引请求中，支持下列参数：
routing: 路由信息，具有相同路由信息的文档存储在同一分片上
parent: 文档的parent id， 如果未设置路由，则会自动将其设置为路由
timestamp: 文档产生的时间戳
ttl: 过期时间
timeout: 超时时间
refresh: 此索引操作之后是否执行刷新，从而使文档可被搜索，默认为false
version: 文档的版本号
version_type: 版本类型，默认internal，支持internal、external、external_gt、external_gte和force
op_type: 索引操作类型，支持create和index
replication: 副本类型，支持async、sync和default
consistency: 一致性，支持one、quorum、all和default
请求的content即索引的source，文档内容
在封装完索引请求后，就要调用 client.index() 执行索引
在index()方法中，使用的Action是IndexAction.INSTANCE
这个action在ActionModule中被TransportIndexAction注册
因此在NodeClient的execute()方法中根据action获取到的transport action为TransportIndexAction
由于TransportIndexAction继承了TransportAction，因此调用过程为NodeClient.execute() - TransportAction.execute() - TransportIndexAction.doExecute()
索引的大体流程为：先判断是否需要创建索引，如果是则先创建索引，然后写入文档数据，否则直接写入文档数据
elasticsearch主要使用AutoCreateIndex.shouldAutoCreate()方法来判断是否需要创建索引
其中参数和globallyDisabled的含义：
action.auto_create_index: elasticsearch配置文件的的配置项，表示是否允许创建索引
needToCheck: 是否需要检查能否创建索引，只有当action.auto_create_index为false时不需要检查，直接返回无法创建索引
globallyDisabled: 是否全局禁用创建索引，只有当action.auto_create_index为false时全局禁用创建索引，直接返回无法创建索引
如果当前集群中已经包含了要创建的索引，那么也不需要创建索引。其他情况则根据action.auto_create_index配置的正则表达式来判断
如果允许创建索引，则开始创建索引名的流程
首先创建 创建索引 的请求createIndexRequest，设置了4个参数，分别是索引名index、索引mapping、创建索引的原因cause和master节点超时时间masterNodeTimeout
然后开始调用createIndexAction.execute()方法创建索引名
从下面的类图可以看出，TransportCreateIndexAction继承了TransportMasterNodeOperation，调用过程即TransportAction.execute()- TransportMasterNodeOperation.doExecute()方法来完成操作
在TransportMasterNodeOperation中主要是保证操作在master节点上执行
这个操作主要保证了两点：
（1）如果当前节点不是master，则将请求发送到master节点执行masterOperation()方法
（2）如果当前集群block了，则等待集群状态更新，然后重新执行完整的innerExecute()方法
然后进入到TransportCreateIndexAction.masterOperation()方法中，创建CreateIndexClusterStateUpdateRequest对象，用来创建索引时更新集群状态信息的请求，其中settings和mappings及aliases默认为空集合
然后调用MetaDataCreateIndexService的createIndex()方法，如果能获取到锁信息则直接执行重载的createIndex()方法，否则交给线程池去执行
在重载从createIndex()方法中，通过提交一个更新集群状态的任务来实现创建索引的具体逻辑
提交StateUpdateTask任务时，会创建一个UpdateTask对象，然后执行其run()方法，即MetaDataCreateIndexService中创建的AckedClusterStateUpdateTask匿名对象
在UpdateTask的run()方法中，会调用ClusterStateUpdateTask.execute()方法获取新的集群状态，
在完成索引创建完成后，集群状态信息会发生变化，elasticsearch会将这个变化发布到其他节点，以维持集群统一的状态信息