4.3.1.Elasticsearch 生产环境集群部署最佳实践
创作人：铭毅天下
在生产环境搭建或维护 Elasticsearch 集群和个人搭建集群的小打小闹有非常大的不同。
本文的最佳实践基于每天增量数亿+的线上环境。
内存
Elasticsearch 和 Lucene 都是 Java 语言编写，这意味着我们必须注意堆内存的设置。
Elasticsearch 可用的堆越多，它可用于过滤器（filter）和其他缓存的内存也就越多，更进一步
讲可以提高查询性能。
但请注意，过多的堆可能会使垃圾回收暂停时间过长。请勿将堆内存的最大值设置为 JVM 用
于压缩对象指针（压缩的 oops）的临界值之上，确切的临界值有所不同，但不要超过 32 GB。
常见内存配置坑 1：堆内存设置过大
举例：Elasticsearch 宿主机：64 GB 内存，堆内存恨不得设置为 64 GB。
这忽略了堆的另一部分内存使用大户：OS 文件缓存。Lucene 旨在利用底层操作系统来缓存内
存中的数据结构。
Lucene 段存储在单独的文件中。由于段是不可变的（immutable），因此这些文件永远不会更改。
这使它们非常易于缓存，并且底层操作系统很乐意将热段驻留在内存中，
以加快访问速度。
这些段包括倒排索引（用于全文搜索）和 doc values 正排索引（用于聚合）。Lucene 的性
能取决于与 OS 文件缓存的交互。如果你将所有可用内存分配给 Elasticsearch 的堆，则 OS
文件缓存将不会剩下任何可用空间。这会严重影响性能。
官方标准建议是：将 50％ 的可用内存（不超过 32 GB，一般建议最大设置为：31 GB）分配
给 Elasticsearch 堆，而其余 50％ 留给 Lucene 缓存。
图片来自网络
可以通过以下方式配置 Elasticsearch 堆：
方式一：堆内存配置文件 jvm.options
# Xms represents the initial size of total heap space # Xmx represents the maximum size of total heap space -Xms16g -Xmx16g
方式二：启动参数设置
ES_JAVA_OPTS="-Xms10g -Xmx10g" ./bin/elasticsearch
CPU
运行复杂的缓存查询、密集写入数据都需要大量的 CPU，因此选择正确的查询类型以及渐进的
写入策略至关重要。
一个节点使用多个线程池来管理内存消耗。与线程池关联的队列，使待处理的请求得以保留（类
似缓冲效果）而不是被丢弃。
由于 Elasticsearch 会做动态分配，除非有非常具体的要求，否则不建议更改线程池和队列大
小。
推荐阅读：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threa
dpool.html
分片数
分片是 Elasticsearch 在集群内分发数据的单位。集群发生故障再恢复平衡的速度，取决于分片
的大小、分片数量、网络以及磁盘性能。
在 Elasticsearch 中，每个查询在每个分片的单个线程中执行。但是，可以并行处理多个分片。
针对同一分片的多个查询和聚合也可以并行处理。这意味着在不涉及缓存的情况下，最小查询
延迟将取决于数据、查询类型以及分片的大小三个因素。
设置很多小分片 VS 设置很少大分片？
· 查询很多小分片，导致每个分片能做到快速响应，但是由于需要按顺序排队和处理结果汇集。
因此不一定比查询少量的大分片快。
· 如果存在多个并发查询，那么拥有大量小分片也会降低查询吞吐量。
所以，就有了下面的分片数如何设定的问题？
分片数设定
选择正确数量的分片是一个复杂问题，因为在集群规划阶段以及在数据写入开始之前，一般不
能确切知道文档数。
对于集群而言，分片数多了以后，索引和分片管理，可能会使主节点超载，并可能会导致集群
无响应，甚至导致集群宕机。
建议：为主节点（Master 节点）分配足够的资源，以应对分片数过多可能导致的问题。
必须强调的是：主分片数是在索引创建时定义的，不支持借助 update API 实现类副本数更新
的动态修改。创建索引后，更改主分片数的唯一方法是重新创建索引，然后将原来索引数据
reindex 到新索引。
官方给出的合理的建议：每个分片数据大小：30GB-50GB。
· 推荐 1：Elasticsearch 究竟要设置多少分片数？
https://elastic.blog.csdn.net/article/details/78080602
· 推荐 2：Elasticsearch 之如何合理分配索引分片
https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
副本
Elasticsearch 通过副本实现集群的高可用性，数据在数据节点之间复制，以实现主分片数据的
备份，因此即便部分节点因异常下线，也不会导致数据丢失。
默认情况下，副本数为 1，但可以根据产品高可用要求将其增加。副本越多，数据的容灾性越
高。
副本多的另一个优点是，每个节点都拥有一个副本分片，有助于提升查询性能。
铭毅提醒：
· 实际副本数增多，提高查询性能建议结合集群做下测试，我实测过效果不明显。
· 副本数增多，意味着磁盘存储要加倍，也考验硬盘空间和磁盘预算。
建议：根据业务实际综合考虑设置副本数。普通业务场景（非精准高可用）副本设置为 1 足够
了。
冷热集群架构配置
根据产品业务数据特定和需求，我们可以将数据分为热数据和冷数据，这是冷热集群架构的前
提。
访问频率更高的索引，可以分配更多更高配（如：SSD）的数据节点，而访问频率较低的索引
可以分配低配（如：机械磁盘）数据节点。
冷热集群架构对于存储，诸如应用程序日志或互联网实时采集数据（基于时间序列数据）特别
有用。
数据迁移策略：通过运行定时任务，来实现定期将索引移动到不同类型的节点。
具体实现：Curator 工具或借助 ILM 索引生命周期管理。
热节点
热节点是一种特定类型的数据节点，关联索引数据是：最近、最新、最热数据。
因为这些热节点数据通常倾向于最频繁地查询。热数据的操作会占用大量 CPU 和 IO 资源，
因此对应服务器需要功能强大（高配）并附加 SSD 存储支持。
针对集群规模大的场景，建议：至少运行 3 个热节点以实现高可用性。
当然，这也和你实际业务写入和查询的数据量有关系，如果数据量非常大，可能会需要增加热
节点数目。
冷节点（或称暖节点）
冷节点是对标热节点的一种数据节点，旨在处理大量不太经常查询的只读索引数据。由于这些
索引是只读的，因此冷节点倾向于使用普通机械磁盘而非 SSD 磁盘。
与热节点对标，也建议：最少 3 个冷节点以实现高可用性。同样需要注意的是，若集群规模非
常大，可能需要更多节点才能满足性能要求。
甚至需要更多类型，如：热节点、暖节点、冷节点等。
强调一下：CPU 和内存的分配最终需要你通过使用与生产环境中类似的环境借助 esrally 性能
测试工具测试确定，而不是直接参考各种最佳实践拍脑袋而定。
有关热节点和热节点的更多详细信息，请参见：
https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x
《Elastic Stack 实战手册》——四、应用实践——4.3 性能优化场景——4.3.1.Elasticsearch 生产环境集群部署最佳实践(2) https://developer.aliyun.com/article/1225320?spm=a2c6h.13148508.setting.15.47564f0eVi9cik
