1.详细描述一下Elasticsearch索引文档的过程
协调节点默认使用文档 ID 参与计算（也支持通过 routing ），以便为路由提供合适的分片。 shard = hash(document_id) % (num_of_primary_shards) 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory Buffffer ，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache ，这个从 Momery Buffffer 到 Filesystem Cache 的过程就叫做 refresh ； 当然在某些情况下，存在 Momery Buffffer 和 Filesystem Cache 的数据可能会丢失， ES 是通过 translog 的机制来 保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据 写入到磁盘中时，才会清除掉，这个过程叫做 flflush ； 在 flflush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷 新到磁盘，旧的 translog 将被删除并开始一个新的 translog 。 flflush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M ）时； 2. 详细描述一下 Elasticsearch 更新和删除文档的过程。 删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更； 磁盘上的每个段都有一个相应的 .del 文件。当删除请求发送后，文档并没有真的被删除，而是在 .del 文件中被标 记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在 .del 文件中被标记为删除的文档 将不会被写入新段。 在新的文档被创建时， Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在 .del 文件中被 标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。 3. 详细描述一下 Elasticsearch 搜索的过程。 搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch ； 在初始 查询阶段 时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索 并构建一个匹配文档的大小为 from + size 的优先队列。 PS ：在搜索的时候是会查询 Filesystem Cache 的，但是 有部分数据还在 Memory Buffffer ，所以搜索是近实时的。 每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生 一个全局排序后的结果列表。 接下来就是 取回阶段 ，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载 并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给 客户端。 补充： Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时 候可能不够准确， DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 document frequency ，这个评分 更准确，但是性能会变差。 4. 在并发情况下， Elasticsearch 如何保证读写一致？ 可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突； 另外对于写操作，一致性级别支持 quorum/one/all ，默认为 quorum ，即只有当大多数分片可用时才允许写操 作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在 一个不同的节点上重建。 对于读操作，可以设置 replication 为 sync( 默认 ) ，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数 _preference 为 primary 来查询主分片，确保文档是最新版 本。 5. 如何监控 Elasticsearch 集群状态？ Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch 。你可以实时查看你的集群健康状态和性能，也可以 分析过去的集群、索引和节点指标。 6.elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数 据大小，分片有多少，以及一些调优手段 。 面试官：想了解应聘者之前公司接触的 ES 使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。 解答： 如实结合自己的实践场景回答即可。 比如： ES 集群架构 13 个节点，索引根据通道不同共 20+ 索引，根据日期，每日递增 20+ ，索引： 10 分片，每日递增 1 亿 + 数据， 每个通道每天索引大小控制： 150GB 之内。 仅索引层面调优手段： 设计阶段调优 1 ）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引； 2 ）使用别名进行索引管理； 3 ）每天凌晨定时对索引做 force_merge 操作，以释放空间； 4 ）采取冷热分离机制，热数据存储到 SSD ，提高检索效率；冷数据定期进行 shrink 操作，以缩减存储； 5 ）采取 curator 进行索引的生命周期管理； 6 ）仅针对需要分词的字段，合理的设置分词器； 7 ） Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。 … 写入调优 1 ）写入前副本数设置为 0 ； 2 ）写入前关闭 refresh_interval 设置为 -1 ，禁用刷新机制； 3 ）写入过程中：采取 bulk 批量写入； 4 ）写入后恢复副本数和刷新间隔； 5 ）尽量使用自动生成的 id 。 查询调优 1 ）禁用 wildcard ； 2 ）禁用批量 terms （成百上千的场景）； 3 ）充分利用倒排索引机制，能 keyword 类型尽量 keyword ； 4 ）数据量大时候，可以先基于时间敲定索引再检索； 5 ）设置合理的路由机制。 其他调优 部署调优，业务调优等。 上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。 7.elasticsearch 是如何实现 master 选举的？ 面试官：想了解 ES 集群的底层原理，不再只关注业务层面了。 解答： 前置前提： 1 ）只有候选主节点（ master ： true ）的节点才能成为主节点。 2 ）最小主节点数（ min_master_nodes ）的目的是防止脑裂。 这个我看了各种网上分析的版本和源码分析的书籍，云里雾里。 核对了一下代码，核心入口为 fifindMaster ，选择主节点成功返回对应 Master ，否则返回 null 。选举流程大致描述如 下： 第一步：确认候选主节点数达标， elasticsearch.yml 设置的值 discovery.zen.minimum_master_nodes ； 第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回；若两节点都为候选主节点，则 id 小的 值会主节点。注意这里的 id 为 string 类型 8.Elasticsearch 中的倒排索引是什么？ 倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。倒排索引是一种像 数据结构一样的散列图，可将用户从单词导向文档或网页。它是搜索引擎的核心。其主要目标是快速搜索从数百万文 件中查找数据。 一般情况下，像下面的一样，在书中我们已经倒过来索引。根据这个词，我们可以找到这个词所在的页面。 9.Elasticsearch 中的分析器是什么？ 在 ElasticSearch 中索引数据时，数据由为索引定义的 Analyzer 在内部进行转换。 分析器由一个 Tokenizer 和零个或多 个 TokenFilter 组成。编译器可以在一个或多个 CharFilter 之前。分析模块允许您在逻辑名称下注册分析器，然后可以 在映射定义或某些 API 中引用它们。 Elasticsearch 附带了许多可以随时使用的预建分析器。或者，您可以组合内置的字符过滤器，编译器和过滤器器来创 建自定义分析器。
