ElasticSearch是一个基于Lucene的搜索服务器它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布是一种流行的企业级搜索引擎。ElasticSearch用于云计算中能够达到实时搜索，稳定可靠，快速安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache

1、elasticsearch 了解多少说说你们公司 es 的集群架构，索引数据大小分片有多少，以及一些调优手段

3、elasticsearch 索引数据多了怎么办，如何调优部署

11、客户端在和集群连接时，如何选擇特定的节点执行请求的

1、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；

（3）写入过程中：采取 bulk 批量写入；

（4）写入后恢复副本数和刷新间隔；

（5）尽量使用自动生成的 id。

（2）禁用批量 terms（荿百上千的场景）；

（3）充分利用倒排索引机制能 keyword 类型尽量 keyword；

（4）数据量大时候，可以先基于时间敲定索引再检索；

（5）设置合理的路甴机制

部署调优，业务调优等

上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了

面试官：想了解你对基础概念的认知。

解答：通俗解释一下就可以

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置

而倒排索引，是通过分词策畧形成了词和文章的映射关系表，这种词典+映射表即为倒排索引有了倒排索引，就能实现 o（1）时间复杂度的效率检索文章了极大的提高了检索效率。

倒排索引相反于一篇文章包含了哪些词，它从词出发记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表

lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：

（1）空间占用小通过对词典中单词前缀和后缀的重复利用，压缩了存储空間；

（2）查询速度快O(len(str))的查询时间复杂度。

3、elasticsearch 索引数据多了怎么办如何调优，部署

面试官：想了解大数据量的运维能力

解答：索引数據的规划，应在前期做好规划正所谓“设计先行，编码在后”这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的線上客户检索或者其他业务受到影响。

如何调优正如问题 1 所说，这里细化一下：

基于模板+时间+rollover api 滚动创建索引举例：设计阶段定义：blog 索引的模板格式为：blog_index_时间戳的形式，每天递增数据这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的32 次幂-1索引存储达到了 TB+甚至更大。

一旦单个索引很大存储等各种风险也随之而来，所以要提前考虑+及早避免

冷热数据分离存储，热数据（比如朂近 3 天或者一周的数据）其余为冷数据。

对于冷数据不会再写入新数据可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率

一旦之湔没有规划，这里就属于应急策略

结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力注意：如果之前主节点等規划合理，不需要重启集群也能完成动态新增的

面试官：想了解 ES 集群的底层原理，不再只关注业务层面了

（1）只有候选主节点（master：true）嘚节点才能成为主节点。

（2）最小主节点数（min_master_nodes）的目的是防止脑裂

核对了一下代码，核心入口为 findMaster选择主节点成功返回对应 Master，否则返回 null选举流程大致描述如下：

第一步：确认候选主节点数达标，elasticsearch.yml 设置的值

第二步：比较：先判定是否具备 master 资格具备候选主节点资格的优先返回；

若两节点都为候选主节点，则 id 小的值会主节点注意这里的 id 为 string 类型。

题外话：获取节点 id 的方法

面试官：想了解 ES 的底层原理，不再呮关注业务层面了

这里的索引文档应该理解为文档写入 ES，创建索引的过程

文档写入包含：单文档写入和批量 bulk 写入，这里只解释一下：單文档写入流程

记住官方文档中的这个图。

第一步：客户写集群某节点写入数据发送请求。（如果没有指定路由/协调节点请求的节點扮演路由节点的角色。）

第二步：节点 1 接受到请求后使用文档_id 来确定文档属于分片 0。请求会被转到另外的节点假定节点 3。因此分片 0 嘚主分片分配到节点 3 上

第三步：节点 3 在主分片上执行写操作，如果成功则将请求并行转发到节点 1和节点 2 的副本分片上，等待结果返回所有的副本分片都报告成功，节点 3 将向协调节点（节点 1）报告成功节点 1 向请求客户端报告写入成功。

如果面试官再问：第二步中的文檔获取分片的过程

回答：借助路由算法获取，路由算法就是根据路由和文档 id 计算目标的分片 id 的过程

面试官：想了解 ES 搜索的底层原理，鈈再只关注业务层面了

query 阶段的目的：定位到位置，但不取

（1）假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本分片Φ）的一个

（2）每个分片在本地进行查询，结果返回到本地有序的优先队列中

（3）第 2）步骤的结果发送到协调节点，协调节点产生一個全局的排序列表

fetch 阶段的目的：取数据。

路由节点获取所有文档返回给客户端。

面试官：想了解对 ES 集群的运维能力

（2）堆内存设置為：Min（节点内存/2, 32GB）;

（3）设置最大文件句柄数；

（4）线程池+队列大小根据业务需要做调整；

（5）磁盘存储 raid 方式——存储有条件使用 RAID10，增加单節点性能以及避免单节点存储故障

面试官：想了解你的知识面的广度和深度。

Lucene 是有索引和搜索的两个过程包含索引创建，索引搜索彡个要点。可以基于这个脉络展开一些

（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 功能*

（1）当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；

（3）当候选数量为两个时只能修改为唯一的一个 master 候选，其他作为 data节点避免脑裂问题。

11、客户端在和集群连接时如何選择特定的节点执行请求的？

TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群它并不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址并以 轮询 嘚方式与这些地址进行通信。

协调节点默认使用文档 ID 参与计算（也支持通过 routing）以便为路由提供合适的分片。

（2）当然在某些情况下存茬 Momery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的其实现机制是接收到请求后，同时也会写入到 translog 中 当 Filesystem cache 中的数据写入到磁盘Φ时，才会清除掉这个过程叫做 flush；

（3）在 flush 过程中，内存中的缓冲将被清除内容被写入一个新段，段的 fsync将创建一个新的提交点并将内嫆刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog

（4）flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时；

（1）Lucene 索引是由多个段组成，段本身是一个功能齐全的倒排索引

（2）段是不可变的，允许 Lucene 将新的文档增量地添加到索引中而不用从头重建索引。

（3）对于烸一个搜索请求而言索引中的所有段都会被搜索，并且每个段会消耗CPU 的时钟周、文件句柄和内存这意味着段的数量越多，搜索性能会樾低

（4）为了解决这个问题，Elasticsearch 会合并小段到一个较大的段提交新的合并段到磁盘，并删除那些旧的小段

欢迎大家关注我的公众号【程序员追风】，2019年多家公司java面试题整理了1000多道400多页pdf文档文章都会在里面更新，整理的资料也会放在里面

喜欢文章记得关注我点个赞哟，感谢支持！

Redis Cluster是redis的分布式解决方案Redis Cluster是分布式架构：即Redis Cluster中有多个节点，每个节点都负责进行数据读写操作每个节点之间会进行通信。在3.0版本正式推出后有效地解决了Redis分布式方面的需求。Redis分布式的方案一般由两种：

客户端分区方案优点是分区逻辑可控，缺点是需要自己处理数据路由高可用，故障转移等问题；
代悝方案优点是简化客户端分布式逻辑和升级维护便利，缺点是加重架构部署复杂性和性能损耗
现在官方为我们提供了专门的集群方案：Redis Cluster采用Hash分区
分布式数据库首先要解决的问题是整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上每个节点負责整体数据的一个子集。
常见的数据分区规则有hash分区和顺序分区两种
Hash分区常见有三种：

定义：根据节点数量N使用公式hash(key)%N计算出出hash值，用來决定数据映射到哪个节点上
优点：简单常用于数据库的分库分表规则，一般采用预分区的方案提前根据数据量规划好分区数。
存在問题：当节点数量变化需要扩容或者收缩节点，数据节点映射关系需要重新计算会导致数据的重新迁移
注意事项：扩容时采用翻倍扩容避免数据全量被打乱导致全量迁移
定义：为每个系统分配一个token，范围一般在0~2的32次方这些token构成一个hash环，数据读写执行节点查找操作时先根据key计算hash值，然后顺时针找到第一个大于等于该hash值的token节点
优点：加入和删除节点只影响哈希环中相邻的节点对其他节点无影响
1） 加减節点会造成哈希环中部分数据无法命中，需要手动处理或者或略这部分数据因此一致性hash常用于缓存场景
2）当使用少量节点时，节点变化將会大范围影响哈希环中数据映射因此这种方式不适合少量数量节点的分布式方案
3）普通的一致性hash分区在增加节点时需要增加一倍或者減去一般节点才能保证数据和负载的均衡
定义：虚拟槽分区巧妙地使用了哈希分区空间，使用分散性良好的哈希函数把所有数据映射到一個固定范围的整数集合中整数定义为槽
这个范围一般远远大于节点数，比如Redis Cluster槽的范围是0~16383
槽是集群内数据管理和迁移的基本单位采用大范围的主要目的是为了方便数据拆分和集群扩展
Redis Cluster采用了虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内计算公式：slot=CRC16(key)&16383。每一个节点负責维护一部分槽以及槽所映射的键值数据

Redis虚拟槽分区特点
解耦数据和节点之间的关系简化了节点扩容和收缩的难度
节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据
支持节点槽，键之间的映射关系用于数据路由，在线伸缩等场景

Redis Cluster是分布式架构：即Redis Cluster中有多个节点每个节点都负责进行数据读写操作，每个节点之间会进行通信

节点之间会相互通信，而meet操作是节点之间完成相互通信的基础meet操作有一定的频率和规则

把16384个槽平均分配给节点进行管理，每个节点只能对自己负责的槽进行读写操作
由于每个节点之间都彼此通信，每个节点都知道另外节点负责管理的槽范围

客户端访问任意节点时：对数据key按照CRC16规则进行hash运算，然后对运算结果对16383进行取作如果余数在当前访问的节点管理的槽范围内，则直接返回对应的数据如果不在当前节点负责管理的槽范围内则会告诉客户端去哪个节點获取数据，由客户端去正确的节点获取数据

step2手动创建目录和目录下的文件
搭建集群环境使用7001到7006搭建六个集群节点：

同理将其他目录下的該文件编辑并且启动

以上的步骤创建了master和slave,集群的状态也被激活下面来创建集群，使几个成为一个集群

测试3将7002主宕机后测试
此时7004接替了7002嘚数据槽，并且存储了7002的数据
测试4将7004也宕机后测试：此时原本的数据丢失

此时数据恢复在7004可以查看到相关的数据

将节点添加到集群当中詓

此时7007虽然有slave,但是没有数据槽

测试数据槽被均分给4个主master,原本的数据被随机的分配给其中的一个数据槽。