1、为什么要使用 Elasticsearch?
系统中的数据， 随着业务的发展， 时间的推移， 将会非常多，而业务中往往采用模糊查询进行数据的 搜索，而模糊查询会导致查询引擎放弃索引， 导致系统查询数据时都是全表扫描，在百万级别的数据库中， 查询效率是非常低下的，而我们使用 ES 做一个全文索引， 将经常查询的系统功能的某些字段，比如说电商系统的商品表中商品名，描述、价格还有 id 这些字段我们放入 ES 索引库里，可以提高查询速度。
2、Elasticsearch 的 master 选举流程？
-
Elasticsearch 的选主是 ZenDiscovery 模块负责的， 主要包含 Ping(节点之间通过这个 RPC 来发现彼此)和 Unicast (单播模块包含一个主机列表以控制哪些节点需要 ping 通)这两部分
-
对所有可以成为 master 的节点(node.master: true)根据 nodeId 字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个(第 0 位)节点， 暂且认为它是 master 节点
-
如果对某个节点的投票数达到一定的值(可以成为 master 节点数 n/2+1) 并且该节点自己也选举自己，那这个节点就是 master 。否则重新选举一直到满足上述条件
-
master 节点的职责主要包括集群、节点和索引的管理， 不负责文档级别的管理；data 节点可以关闭 http功能
3、Elasticsearch 集群脑裂问题？
所谓脑裂问题（类似于精神分裂），就是同一个集群中的不同节点，对于集群的状态有了不一样的理解。
由于某些节点的失效，部分节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况成为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群会同时索引和修改集群的数据。
“脑裂”问题可能的成因：
-
网络问题：集群间的网络延迟导致一些节点访问不到 master，认为 master 挂掉了从而选举出新的master，并对 master 上的分片和副本标红，分配新的主分片
-
节点负载：主节点的角色既为 master 又为 data，访问量较大时可能会导致 ES 停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
-
内存回收：data 节点上的 ES 进程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 进程失去响应
脑裂问题解决方案：
-
减少误判：discovery.zen.ping_timeout 节点状态的响应时间， 默认为 3s，可以适当调大，如果 master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数(如 6s ， discovery.zen.ping_timeout:6 ) ，可适当减少误判。
-
选举触发:
discovery.zen.minimum_master_nodes:1，该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值， 且备选主节点中有该参数个节点认为主节点挂了， 进行选举。官方建议为(n/2) +1，n 为主节点个数 (即有资格成为主节点的节点个数) -
角色分离：即 master 节点与data 节点分离，限制角色
-
主节点配置为：node.master: true node.data: false
-
从节点配置为：node.master: false node.data: true
-
4、elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段 。
面试官：想了解应聘者之前公司接触的 ES 使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。
解答：如实结合自己的实践场景回答即可。
比如：ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，每日递增 20+，索引：10分片，每日递增 1 亿+数据，每个通道每天索引大小控制：150GB 之内。
仅索引层面调优手段：
设计阶段调优
-
根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
-
使用别名进行索引管理；
-
每天凌晨定时对索引做 force_merge 操作，以释放空间；
-
采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；
-
采取 curator 进行索引的生命周期管理；
-
仅针对需要分词的字段，合理的设置分词器；
-
Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..
写入调优
-
写入前副本数设置为 0；
-
写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
-
写入过程中：采取 bulk 批量写入；
-
写入后恢复副本数和刷新间隔；
-
尽量使用自动生成的 id。
查询调优
-
禁用 wildcard；
-
禁用批量 terms（成百上千的场景）；
-
充分利用倒排索引机制，能 keyword 类型尽量 keyword；
-
数据量大时候，可以先基于时间敲定索引再检索；
-
设置合理的路由机制
5.在并发情况下，Elasticsearch 如果保证读写一致？
-
可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
-
对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用， 也可能存在因为网络等原因导致写入副本失败， 这样该副本被认为故 障，分片将会在一个不同的节点上重建。
-
对于读操作， 可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片， 确保文档是最新版本。
