序文
ElasticSearchはLuceneをベースと検索サーバーです。これは、RESTfulなWebインターフェイスに基づいて、フルテキスト検索エンジンの分散型マルチユーザ機能を提供します。Elasticsearchは、Java言語の開発であり、公表されApacheのライセンス条件の下でオープンソースとして、人気の高いエンタープライズクラスの検索エンジンです。ElasticSearchは、クラウドコンピューティングのために、インストールするために迅速かつ簡単に、リアルタイム検索、安定した、信頼性の高いを達成することが可能です。Javaや.NET（C＃）と、PHP、Pythonのは、ApacheのGroovy、Rubyや他の多くの言語での公式のクライアントが利用可能です。DB-エンジンによるとランキングが表示され、Elasticsearch企業向け検索エンジンは、LuceneをベースにApache Solrの、続く、最も人気があります。
Elasticsearchフェイス質問
1は、elasticsearchは、あなたの会社がクラスタアーキテクチャ、インデックスデータサイズ、フラグメントの数だけでなく、いくつかのチューニング手段をESについて話をどのくらい知っています。
2.逆elasticsearch何インデックスです
3、elasticsearchインデックスデータより、どのように調整するために、デプロイを行う方法
4、elasticsearchはマスター選挙を実現する方法であります
5、どのようなElasticsearchドキュメントのインデックス作成プロセスの詳細な説明
6、プロセスElasticsearch検索についての詳細な説明？
Linux用に設定されている7、展開時Elasticsearch、最適化手法
内部構造をlucence何8.？
9、Elasticsearchは、マスターの選挙を実現する方法ですか？
10、Elasticsearchノード（例えば、20の合計）10がマスタを選択し、そのうちの、他の10は、どのように、別のマスターを選びましたか？
図11に示すように、クライアントとクラスタの接続は、どのように要求しているノードの具体的な実装を選択するには？
12は、詳細に文書のElasticsearch指数のプロセスを説明します。
1は、elasticsearchは、あなたの会社がクラスタアーキテクチャ、インデックスデータサイズ、フラグメントの数だけでなく、いくつかのチューニング手段をESについて話をどのくらい知っています。
インタビュアー：候補者のシーンの前にESの会社の連絡先を使用するために、スケールは、大規模な比較指標の設計、計画、チューニングを行っていません。
回答：正直に答えるために、独自の練習のシナリオで。
例えば：ESクラスタアーキテクチャ13個の20 +指数異なるチャネルの合計によってインデックス付けノード、日付によると、日20+増分インデックス：10個のスライス、100 000 000 +データ毎日、毎日の制御チャネルインデックスサイズインクリメントされる：150ギガバイト内。
唯一のインデックスレベルのチューニング・ツール：
1.1、設計段階のチューニング
日付テンプレートに基づいてインデックスを作成するために取るために増分ビジネスニーズに基づいて（1）、APIロールインデックスロールオーバー。
エイリアスインデックス管理を用いて（2）。
（3）は空きスペースに、毎朝のforce_merge動作タイミング指標を行います。
SSDデータストレージを加熱するために、冷たいを採取（4）分離機構は、検索効率が改善され、常温収縮操作データは、定期的に、メモリを削減するために、
（5）キュレーターライフサイクル管理指標を取ります。
（6）のみサブワードフィールドのニーズのために、合理的なワードブレーカを設定します。
（7）マッピング位相十分な結合、各フィールドのプロパティ、取得する必要があり、ストレージの必要性。...... ..
1.2、書き込みチューン
（1）コピー数が0に設定されている書き込む前に、
無効リフレッシュ機構に、-1にREFRESH_INTERVALセットを書き込む前にオフ（2）;
（3）書き込み処理：バルク一括書き込みを取ります。
（4）コピーとライトリカバリリフレッシュ間隔の数。
（5）自動生成されたIDを利用します。
1.3、クエリのチューニング
（1）無効ワイルドカード。
（2）無効にバッチ用語（シーンの数百）。
（3）逆インデックス機構の完全な使用、キーワード、キーワードを入力しようとすることができます。
データの量は、再検索インデックスまでの時間に基づいて確定される（4）。
（5）は、合理的なルーティングメカニズムを設定します。
1.4その他のチューニング
チューニングの展開、サービスは優秀試運転。
パートは、上記の練習や運用・保守経験する前に、インタビュアーは、基本的に評価されます。
2.逆elasticsearch何インデックスです
インタビュアー：あなたは基本的な認知概念を学びたいと思います。
ANSWER：人気の説明をすることができます。
私たちの伝統は、対応する位置を見つけるために、記事を一つずつトラバースキーワードが検索されます。
逆索引は、マッピングテーブルの単語や物品を形成する、単語戦略であり、この辞書+マッピングテーブルは転置インデックスです。転置インデックスと、検索された物品の効率のO（1）時間の複雑さを達成することができ、大幅検索効率を向上させることができるであろう。
アカデミック回答方法：
倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。
加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。
lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：
（1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
（2）查询速度快。O(len(str))的查询时间复杂度。
3、elasticsearch 索引数据多了怎么办，如何调优，部署
面试官：想了解大数据量的运维能力。
解答：索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。
如何调优，正如问题 1 所说，这里细化一下：
3.1 动态索引层面
基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索引的模板格式为：blog_index_时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的32 次幂-1，索引存储达到了 TB+甚至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
3.2 存储层面
冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率。
3.3 部署层面
一旦之前没有规划，这里就属于应急策略。
结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。
4、elasticsearch 是如何实现 master 选举的
面试官：想了解 ES 集群的底层原理，不再只关注业务层面了。
解答：
前置前提：
（1）只有候选主节点（master：true）的节点才能成为主节点。
（2）最小主节点数（min_master_nodes）的目的是防止脑裂。
核对了一下代码，核心入口为 findMaster，选择主节点成功返回对应 Master，否则返回 null。选举流程大致描述如下：
第一步：确认候选主节点数达标，elasticsearch.yml 设置的值
discovery.zen.minimum_master_nodes；
第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回；
若两节点都为候选主节点，则 id 小的值会主节点。注意这里的 id 为 string 类型。
题外话：获取节点 id 的方法。
1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name 2ip port heapPercent heapMax id name
5、详细描述一下 Elasticsearch 索引文档的过程
面试官：想了解 ES 的底层原理，不再只关注业务层面了。
解答：
这里的索引文档应该理解为文档写入 ES，创建索引的过程。
文档写入包含：单文档写入和批量 bulk 写入，这里只解释一下：单文档写入流程。
记住官方文档中的这个图。
第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演路由节点的角色。）
第二步：节点 1 接受到请求后，使用文档_id 来确定文档属于分片 0。请求会被转到另外的节点，假定节点 3。因此分片 0 的主分片分配到节点 3 上。
第三步：节点 3 在主分片上执行写操作，如果成功，则将请求并行转发到节点 1和节点 2 的副本分片上，等待结果返回。所有的副本分片都报告成功，节点 3 将向协调节点（节点 1）报告成功，节点 1 向请求客户端报告写入成功。
如果面试官再问：第二步中的文档获取分片的过程？
回答：借助路由算法获取，路由算法就是根据路由和文档 id 计算目标的分片 id 的过程。
1shard = hash(_routing) % (num_of_primary_shards)
6、详细描述一下 Elasticsearch 搜索的过程？
面试官：想了解 ES 搜索的底层原理，不再只关注业务层面了。
解答：
搜索拆解为“query then fetch” 两个阶段。
query 阶段的目的：定位到位置，但不取。
步骤拆解如下：
（1）假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本分片中）的一个。
（2）每个分片在本地进行查询，结果返回到本地有序的优先队列中。
（3）第 2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。
fetch 阶段的目的：取数据。
路由节点获取所有文档，返回给客户端。欢迎大家关注我的公种浩【程序员追风】，2019年多家公司java面试题整理了1000多道400多页pdf文档，文章都会在里面更新，整理的资料也会放在里面。
7、Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法
面试官：想了解对 ES 集群的运维能力。
解答：
（1）关闭缓存 swap;
（2）堆内存设置为：Min（节点内存/2, 32GB）;
（3）设置最大文件句柄数；
（4）线程池+队列大小根据业务需要做调整；
（5）磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单节点存储故障。
8、lucence 内部结构是什么？
面试官：想了解你的知识面的广度和深度。
解答：
Lucene 是有索引和搜索的两个过程，包含索引创建，索引，搜索三个要点。可以基于这个脉络展开一些。
9、Elasticsearch 是如何实现 Master 选举的？
（1）Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含 Ping（节点之间通过这个 RPC 来发现彼此）和 Unicast（单播模块包含一个主机列表以控制哪些节点需要 ping 通）这两部分；
（2）对所有可以成为 master 的节点（node.master: true）根据 nodeId 字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第 0 位）节点，暂且认为它是 master 节点。
（3）如果对某个节点的投票数达到一定的值（可以成为 master 节点数 n/2+1）并且该节点自己也选举自己，那这个节点就是 master。否则重新选举一直到满足上述条件。
（4）补充：master 节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data 节点可以关闭 http 功能*。
10、Elasticsearch 中的节点（比如共 20 个），其中的 10 个
选了一个 master，另外 10 个选了另一个 master，怎么办？
（1）当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；
（3）当候选数量为两个时，只能修改为唯一的一个 master 候选，其他作为 data节点，避免脑裂问题。
11、客户端在和集群连接时，如何选择特定的节点执行请求的？
TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址，并以 轮询 的方式与这些地址进行通信。
12、详细描述一下 Elasticsearch 索引文档的过程。
协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合适的分片。
shard = hash(document_id) % (num_of_primary_shards)
（1）ノードは、コーディネータノードから要求を受信断片配置されている場合、要求はMemoryBufferに書き込まれ、そしてタイミング（デフォルトでは1秒）がMomeryBufferからこのプロセスに、ファイルシステムキャッシュに書き込まれているファイルシステムはキャッシュでありますリフレッシュと呼ばれます。
（2）はもちろん、いくつかのケースでは、Momeryバッファとファイルシステムのキャッシュデータは、データの信頼性を確保するためのメカニズムを介して、ESトランスログ失われる可能性があります。その実装の要求を受信した後機構だけでなく、トランスログに書き込まれ、データがディスクにファイル・システム・キャッシュに書き込まれるときに、フラッシュと呼ばれるプロセスが除去されます。
フラッシュ工程（3）は、メモリ・バッファがクリアされ、コンテンツが新しいセグメントに書き込まれ、セグメントFSYNCが新しいコミットポイントが作成され、その内容がディスクにフラッシュ、古いトランスログは削除され、開始され新しいトランスログ。
（4）フラッシュトリガタイミングは、タイミングトリガ（デフォルト30分）またはトランスログ（デフォルトは512Mである）場合に大きくなりすぎ。
補足：Luceneの上Segement：
（1）Luceneインデックスは、複数のセグメントから構成され、セグメント自体は、完全に機能する逆インデックスです。
パラグラフ（2）は不変であり、新たなドキュメントがLuceneのが増分ゼロからインデックスを再構築するのではなく、インデックスに追加できます。
（3）各検索要求のために、インデックスは、すべてのセグメントが検索され、各セグメントは、CPU、メモリ、およびファイルハンドルのクロックサイクルを消費します。この手段はより大きなセグメントの数は、検索性能が低くなります。
（4）この問題を解決するために、Elasticsearch小片は、より大きなセグメントにマージされますディスクにマージされた新しいセグメントを提出し、小片に古いものを削除します。
遂に
私は、ヨーヨーのような支援への感謝をポイントを集中記事を覚えているようなみんなと共有へようこそ！