17、对于 GC 方面，在使用 Elasticsearch 时要注意什么？
1、SEE：https://elasticsearch.cn/article/32
2、倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segment
memory 增长趋势。
3、各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要
设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓
存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache
等“自欺欺人”的方式来释放内存。
4、避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用
scan & scroll api 来实现。
5、cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集
群通过 tribe node 连接。
6、想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做
持续的监控。
第 96 页 共 485 页18、Elasticsearch 对于大数据量（上亿量级）的聚合如何实现？
Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数，
即该字段的 distinct 或者 unique 值的数目。它是基于 HLL 算法的。HLL 会先对
我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到
基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；
小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内
存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。
19、在并发情况下，Elasticsearch 如果保证读写一致？
1、可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用
层来处理具体的冲突；
2、另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只
有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络
等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点
上重建。
3、对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副
本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜
索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。
20、如何监控 Elasticsearch 集群状态？
Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你
的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。
