ES⾯试题
在并发情况下，Ela stic a rc h如果保证读写⼀致？
可以通过版本号使⽤乐观并发控制，以确保新版本不会被旧版本覆盖，由应⽤层来处理具体的冲突；
另外对于写操作，⼀致性级别⽀持quorum/one/all，默认为quorum，即只有当⼤多数分⽚可⽤时才允许写操作。但即使⼤多数可⽤，也可能存在因为⽹络等原因导致写⼊副本失败，这样该副本被认为故障，分⽚将会在⼀个不同的节点上重建。
对于读操作，可以设置replication为sync(默认)，这使得操作在主分⽚和副本分⽚都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分⽚，确保⽂档是最新版本。
Ela stic a r c h对于⼤数据量（上亿量级）的聚合如何实现？
Elasticarch 提供的⾸个近似聚合是cardinality 度量。它提供⼀个字段的基数，即该字段的distinct或者unique值的数⽬。它是基于HLL算法的。HLL 会先对我们的输⼊作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从⽽得到基数。其特点是：可配置的精度，⽤来控制内存的使⽤（更精确 ＝ 更多内存）；⼩的数据集精度是⾮常⾼的；我们可以通过配置参数，来设置去重需要的固定内存使⽤
量。⽆论数千还是数⼗亿的唯⼀值，内存使⽤量只与你配置的精确度相关。
对于GC⽅⾯，在使⽤Ela stic a rc h时要注意什么？
倒排词典的索引需要常驻内存，⽆法GC，需要监控data node上gment memory增长趋势。
各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的⼤⼩，并且要应该根据最坏的情况来看heap是否够⽤，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采⽤clear cache等“⾃欺欺⼈”的⽅式来释放内存。
避免返回⼤量结果集的搜索与聚合。确实需要⼤量拉取数据的场景，可以采⽤scan & scroll api来实现。
cluster stats驻留内存并⽆法⽔平扩展，超⼤规模集群可以考虑分拆成多个集群通过tribe node连接。
想知道heap够不够，必须结合实际应⽤场景，并对集群的heap使⽤情况做持续的监控。
Ela stic a r c h在部署时，对Linux的设置有哪些优化⽅法？
64 GB 内存的机器是⾮常理想的， 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反。
如果你要在更快的 CPUs 和更多的核⼼之间选择，选择更多的核⼼更好。多个内核提供的额外并发远胜过稍微快⼀点点的时钟频率。
如果你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是⼀个好的选择。即使数据中⼼们近在咫尺，也要避免集群跨越多个数据中⼼。绝对要避免集群跨越⼤的地理距离。
请确保运⾏你应⽤程序的 JVM 和服务器的 JVM 是完全⼀样的。 在 Elasticarch 的⼏个地⽅，使⽤ Java 的本地序列化。
通过设置ver_after_nodes、pected_nodes、ver_after_time可以在集群重启的时候避免过多的分⽚交换，这可能会让数据恢复从数个⼩时缩短为⼏秒钟。
Elasticarch 默认被配置为使⽤单播发现，以防⽌节点⽆意中加⼊集群。只有在同⼀台机器上运⾏的节点才会⾃动组成集群。最好使⽤单播代替组播。
不要随意修改垃圾回收器（CMS）和各个线程池的⼤⼩。
把你的内存的（少于）⼀半给 Lucene（但不要超过 32 GB！），通过ES_HEAP_SIZE 环境变量设置。
内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，⼀个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。
Lucene 使⽤了⼤量的⽂件。同时，Elasticarch 在节点和 HTTP 客户端之间进⾏通信也使⽤了⼤量的套接字。 所有这⼀切都需要⾜够的⽂件描述符。你应该增加你的⽂件描述符，设置⼀个很⼤的值，如 64,000。
补充：索引阶段性能提升⽅法
使⽤批量请求并调整其⼤⼩：每次批量数据 5–15 MB ⼤是个不错的起始点。
存储：使⽤ SSD
段和合并：Elasticarch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你⽤的是 SSD，可以考虑提⾼到 100–200 MB/s。如果你在做批量导⼊，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 anslog.flush_threshold_size 设置，从默认的 512 MB 到更⼤⼀些的值，⽐如 1 GB，这可以在⼀次清空触发的时候在事务⽇志⾥积累出更⼤的段。
如果你的搜索结果不需要近实时的准确度，考虑把每个索引的fresh_interval 改到30s。
如果你在做⼤批量导⼊，考虑通过设置index.number_of_replicas: 0 关闭副本。
Bulk Queue
⼀般来说，Bulk queue不会消耗很多的heap，但是见过⼀些⽤户为了提⾼bulk的速度，客户端设置了很⼤的并发量，并且将bulk Queue设置到不可思议的⼤，⽐如好⼏千。 Bulk Queue是做什么⽤的？当所有的bulk thread都在忙，⽆法响应新的bulk request的时候，将request在内存⾥排列起来，然后慢慢清掉。 这在应对短暂的请求爆发的时候有⽤，但是如果集群本⾝索引速度⼀直跟不上，设置的好⼏千的queue都满了会是什么状况呢？ 取决于⼀个bulk的数据量⼤⼩，乘上queue的⼤⼩，heap很有可能就不够⽤，内存溢出了。⼀般来说官⽅默认的thread pool设置已经能很好的⼯作了，建议不要随意去“调优”相关的设置，很多时候都是适得其反的效果。
Indexing Buffer
Indexing Buffer是⽤来缓存新数据，当其满了或者refresh/flush interval到了，就会以gment file的形式写⼊到磁盘。 这个参数的默认值是10% heap size。根据经验，这个默认值也能够很好的⼯作，应对很⼤的索引吞吐量。 但有些⽤户认为这个buffer越⼤吞吐量越⾼，因此见过有⽤户将其设置为40%的。到了极端的情况，写⼊速度很⾼的时候，40%都被占⽤，导致OOM。
Cluster State Buffer
ES被设计成每个node都可以响应⽤户的api请求，因此每个node的内存⾥都包含有⼀份集群状态的拷贝。这个cluster state包含诸如集群有多少个node，多少个index，每个index的mapping是什么？有少shard，每个shard的分配情况等等 (ES有各类stats api获取这类数据)。 在⼀个规模很⼤的集群，这个状态信息可能会⾮常⼤的，耗⽤的内存空间就不可忽视了。并且在ES2.0之前的版本，state的更新是由master node做完以后全量散播到其他结点的。 频繁的状态更新都有可能给heap带来压⼒。 在超⼤规模集群的情况下，可以考虑分集群并通过tribe node连接做到对⽤户api的透明，这样可以保证每个集群⾥的state信息不会膨胀得过⼤。
超⼤搜索聚合结果集的fetch
ES是分布式搜索引擎，搜索和聚合计算除了在各个data node并⾏计算以外，还需要将结果返回给汇总节点进⾏汇总和排序后再返回。⽆论是搜索，还是聚合，如果返回结果的size设置过⼤，都会给heap造成很⼤的压⼒，特别是数据汇聚节点。超⼤的size多数情况下都是⽤户⽤例不对，⽐如本来是想计算cardinality，却⽤了terms aggregation + size:0这样的⽅式; 对⼤结果集做深度分页；⼀次性拉取全量数据等等。
⼩结：
1. 倒排词典的索引需要常驻内存，⽆法GC，需要监控data node上gment memory增长趋势。
2. 各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的⼤⼩，并且要应该根据最坏的情况来看heap是否够
⽤，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采⽤clear cache等“⾃欺欺⼈”的⽅式来释放内存。
3. 避免返回⼤量结果集的搜索与聚合。缺失需要⼤量拉取数据可以采⽤scan & scroll api来实现。
4. cluster stats驻留内存并⽆法⽔平扩展，超⼤规模集群可以考虑分拆成多个集群通过tribe node连接。
查询性能
查询性能中routing⾮常重要,
分合: 在实践过程中，索引越来越⼤，那么单个shard分⽚也越来越⼤，查询速度也越来越慢.
是选择分索引还是分shards?
实验中更多的shards会带来额外的IO压⼒.
Elastic 官⽅⽂档建议：⼀个 Node 最好不要多于三个 shards。
线程池
线程池我们默认使⽤ fixed，使⽤ cached 有可能控制不好。主要是⽐较⼤的分⽚ relocation时，会导致分⽚⾃动下线，集群可能处于危险状态。在集群⾼压时，若是 cached ，分⽚也可能⾃动下线。
