elasticsearch5.0 必须要2g内存吗

可以通过命令行参数的形式，在程序启动的时候把内存大小传递给它：
/bin/elasticsearch -Xmx10g -Xms10g
备注:确保Xmx和Xms的大小是相同的，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源，可以减轻伸缩堆大小带来的压力。
一般来说设置ES_HEAP_SIZE环境变量，比直接写-Xmx10g -Xms10g更好一点。

一个 Elasticsearch 集群由一个或多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识。

一个 Elasticsearch 实例即一个 Node，一台机器可以有多个实例，正常使用下每个实例应该会部署在不同的机器上。Elasticsearch 的配置文件中可以通过 nodemaster、nodedata 来设置节点类型。

nodemaster：表示节点是否具有成为主节点的资格
nodedata：表示节点是否存储数据

节点即有成为主节点的资格，又存储数据。这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。Elasticsearch 默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，这样相当于主节点和数据节点的角色混合到一块了。

节点没有成为主节点的资格，不参与选举，只会存储数据。在集群中需要单独设置几个这样的节点负责存储数据，后期提供存储和查询服务。主要消耗磁盘，内存。

不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。普通服务器即可(CPU、内存消耗一般)。

不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡。普通服务器即可（如果要进行分组聚合 *** 作的话，建议这个节点内存也分配多一点）

在生产环境下，如果不修改 Elasticsearch 节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。

一个集群下可以有多个索引，每个索引是一系列相同格式文档的集合 （Elasticsearch 6x 已不支持一个索引下多个Type） 。

每个索引有一个或多个分片，每个分片存储不同的数据。分片可分为主分片（ primary shard）和复制分片（replica shard），复制分片是主分片的拷贝。默认每个主分片有一个复制分片（默认一个索引创建后会有5个主分片，即：5主+5复制=10个分片），一个索引的复制分片的数量可以动态地调整，复制分片从不与它的主分片在同一个节点上（防止单点故障）。

复制分片有两个作用：

根据以下说明调整 elasticsearchyml 对应参数配置，node2、node3 其他配置与node1一致。

到目前位置，集群的配置就完成了，下面我们分别启动每个实例。

根据配置文件中的注释：

所以我们配置了 discoveryzenminimum_master_nodes: 2 ，所以必须有两个主节点启动成功，集群才算生效。

进入目录 elasticsearch-621-1 启动第一个节点，执行命令：bin\elasticsearchbat。从日志中可以看出并没有成功，因为没发现足够的master节点。

当第二个master节点启动成功时，整个集群状态变为正常。

3个节点全部启动成功，通过 elasticsearch-head 插件查看集群状态，通过集群健康值：green，表示集群一切正常。目前集群内没有任何数据，所以看不出索引与分片的情况。

Elasticsearch 一般会配合 Kibana + X-Pack 对集群数据分析、监控等，官方标配。这里使用了 elasticsearch-head 插件，一个比较小巧的工具。插件的安装方法请看： elasticsearch-head 安装介绍

添加测试数据：

从截图可以看出，目前一共3个节点，一个索引 test，test 索引有5个主分片（边框加粗），5个复制分片（边框不加粗），分片会别均匀的分布到每个节点中。

我们尝试干掉node3，node3 从集群退出之后，集群在短时间内会对分片进行重新分布，当然依赖遵循主、复制分片不会在同一个Node。

如果我们继续把node2干掉，那么整个集群就挂了，集群健康值：未连接。因为当前可用的主节点数 1 < discoveryzenminimum_master_nodes 设置的 2。

我们尝试把 discoveryzenminimum_master_nodes 设置成 1，然后重启启动一个节点，会发现有一个 Unassigned 的节点，集群健康值：yellow (5 of 10)。这种情况下代表主分片全部可用，存在不可用的复制分片，5个复制分片没有分配到节点上，不过此时的集群是可用的，我们任何请求都能处理，只是所有的 *** 作都落到主分片上，而且可能引发单点故障。当我们把第二个节点启动后，一切就恢复正常了，主分片的数据会同步到复制分片。

实际生产环境，每个节点可能设置不同的节点类型，我们在3个节点的基础上再增加两个节点，然后调整 nodemaster 和nodedata 的值，最终设置为2个主节点，2个数据节点，1个客户端节点。

node1 和 node2 是具有主节点选举权限的节点，这里 node1 被选举为master节点。node3 和 node4 是数据节点，所以数据分片只会分配在这两个节点上。node5 是客户端节点，最终是对请求起到负载均衡的作用。

如果是Linux环境下，启动可能没有这么顺利，可以参考 Linux 环境下安装 elasticsearch 5x、6x 问题汇总 。

a) JVM内存设置不要超过机器的一半内存，并且不超过32G。（/bin/elasticsearch -Xmx10g -Xms10g或者修改/bin/elasticsearchinsh文件：

一般分配主机1/4-1/2的内存

设置每个线程的堆栈大小, ES单线程承载的数据量比较大
JAVA_OPTS="$JAVA_OPTS -Xss128m"

b) 修改swapping参数，内存不够用时才进行swapping（vmswappiness= 1）
c) 暂时不要修改GC方法
d）锁定内存，不让JVM写入swapping，避免降低ES的 性能
bootstrapmlockall: true
e）缓存类型设置为Soft Reference，只有当内存不够时才会进行回收
indexcachefieldmax_size: 50000 indexcachefieldexpire: 10m indexcachefieldtype: soft

4权衡建索引的性能和检索的时效性，修改以下参数。

5倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment
memory增长趋势。

定期对不再更新的索引做optimize (ES20以后更改为force merge api)。这Optimze的实质是对segment file强制做合并，可以节省大量的segment memory

6根据机器数，磁盘数，索引大小等硬件环境，根据测试结果，设置最优的分片数和备份数，单个分片最好不超过10GB，定期删除不用的索引，做好冷数据的迁移。

7保守配置内存限制参数，尽量使用doc value存储以减少内存消耗，查询时限制size、from参数。

8如果不使用_all字段最好关闭这个属性，否则在创建索引和增大索引大小的时候会使用额外更多的CPU，如果你不受限CPU计算能力可以选择压缩文档的_source。这实际上就是整行日志，所以开启压缩可以减小索引大小。

9避免返回大量结果集的搜索与聚合。缺失需要大量拉取数据可以采用scan & scroll api来实现。

10熟悉各类缓存作用，如field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用。

11必须结合实际应用场景，并对集群使用情况做持续的监控。

---