核心内容摘要
打破沉默，重塑自我：科技赋能下的“干逼软件”新篇章
文章目录Elasticsearch 面试题
1 为什么要使用Elasticsearch?
2 Elasticsearch的master选举流程
3 Elasticsearch集群脑裂问题
4 Elasticsearch索引文档的流程
5 Elasticsearch更新和删除文档的流程
6 Elasticsearch搜索的流程
7 Elasticsearch 在部署时对 Linux 的设置有哪些优化方法
8 GC方面在使用Elasticsearch时要注意什么
9 在并发情况下Elasticsearch如果保证读写一致
11 如何监控 Elasticsearch 集群状态
12 Elasticsearch 是否了解字典树
13 Elasticsearch中的集群、节点、索引、文档、类型是什么
14 Elasticsearch中的倒排索引是什么Elasticsearch 面试题
1 为什么要使用Elasticsearch?传统mysql中过百万的数据做模糊查询效率很低es转为文本索引而生
2 Elasticsearch的master选举流程候选节点node.master: true在 master 缺失时触发选举。
节点通过 Ping 交换信息依据 “集群状态版本更高(整个集群的状态版本信息最高拥有最新地图)优先、节点 ID 更小次之” 的规则竞选。
需获得超过 “过半”(候选节点数 /
1的投票含自身才能当选。
当选后同步集群状态完成选举。
3 Elasticsearch集群脑裂问题原因网络问题节点间通信中断各部分以为对方挂了各自选主节点负载过高主节点因繁忙没及时响应被误认为故障配置不当最小主节点数设置不合理解决方案合理设置discovery.zen.minimum_master_nodes值为「半数以上」确保少数派无法选主优化网络用稳定网络增加超时时间discovery.zen.ping_timeout控制节点负载避免主节点过载可分离主节点和数据节点
4 Elasticsearch索引文档的流程客户端发送文档到任意节点协调节点协调节点计算文档属于哪个分片根据 ID 哈希转发请求到该分片的主节点主节点写入文档并同步给副本节点所有副本确认后主节点返回成功给客户端简单说客户端→协调节点→主分片→副本分片→确认成功
5 Elasticsearch更新和删除文档的流程更新流程a) 客户端发更新请求到任意节点协调节点b) 协调节点找到文档所在的主分片c) 主分片先标记旧文档为删除状态再创建新文档ES 不直接修改原文档d) 同步新文档到副本分片e) 所有副本确认后返回成功删除流程a) 客户端发删除请求到协调节点b) 协调节点找到文档所在的主分片c) 主分片标记文档为删除状态不直接物理删除后续由 ES 定期清理d) 同步删除标记到副本分片e) 所有副本确认后返回成功简单说都是先找主分片做标记更新是标记旧的 建新的删除是只标记同步副本后完事。
6 Elasticsearch搜索的流程客户端发搜索请求到任意节点协调节点协调节点确定需要查询的所有分片主或副本均可并行向这些分片发送查询请求获取候选结果limit100 协调节点汇总、排序所有结果返回给客户端3个节点各返回100条再limit100返回
7 Elasticsearch 在部署时对 Linux 的设置有哪些优化方法硬件配置内存优先选
GB8GB 以下性能会受影响分配给 ES 的堆内存不超过物理内存一半且上限 32GB剩余内存留给 Lucene 缓存文件提升性能。
CPU 核心数比主频更重要多核心支持更高并发。
优先用 SSD读写性能远超机械硬盘尤其提升查询和索引速度。
集群部署避免跨数据中心或地理距离部署网络延迟会严重影响集群协同。
用单播发现节点默认防止无关节点误加入不要用组播。
系统设置禁用内存交换swap否则会导致操作延迟从微秒级飙升到毫秒级严重拖慢性能。
调大文件描述符限制如设为 64000因为 Lucene 和网络通信会用到大量文件和套接字。
JVM 与配置确保应用与 ES 用相同 JVM 版本避免序列化问题。
不随意修改默认垃圾回收器CMS和线程池配置保持官方优化的平衡。
集群重启时通过 gateway 相关参数如recover_after_nodes控制分片恢复节奏缩短启动时间。
索引方面批量导入用批量请求提交数据单次批量大小控制在 5–15MB 起步可根据实际调整减少请求开销。
硬件加速用 SSD 存储显著提升索引读写速度机械盘瓶颈明显。
优化段合并SSD 可将合并速率从默认 20MB/s 提高到 100–200MB/s纯批量导入时可关闭限流牺牲搜索性能换写入速度。
调大事务日志刷新阈值如从 512MB 到 1GB积累更大段再刷新减少合并次数。
放宽实时性若不需近实时搜索将索引刷新间隔index.refresh_interval调至 30 秒默认 1 秒减少刷新开销。
临时关闭副本批量导入时先设副本数为 0index.number_of_replicas: 0完成后再恢复避免副本同步消耗资源。
8 GC方面在使用Elasticsearch时要注意什么倒排词典索引常驻内存不会被回收要盯着数据节点上这部分内存的增长各种缓存字段、过滤、索引等要设合适大小确保满负荷时还有内存给其他任务别用清缓存自欺欺人别返回太多搜索和聚合结果大量取数用 scan scroll 接口超大规模集群可拆分避免集群统计信息占用内存过多内存够不够得结合实际场景持续监控
9 在并发情况下Elasticsearch如果保证读写一致乐观锁控版本冲突通过文档版本号控制新版本不会办法覆盖旧版本冲突由应用层处理比如重试或提示避免并发写入互相覆盖。
写操作的一致性保障默认要求 “大多数分片可用”quorum才允许写入确保集群多数节点能接收数据。
即使偶发副本同步失败也会标记故障分片并在新节点重建最终保证数据一致。
读操作的实时性控制默认同步读写replicationsync需主分片和副本都写完才返回读时能拿到最新数据。
若用异步写入async可指定优先读主分片_preferenceprimary确保读到最新版本。
核心逻辑是用版本号防冲突靠分片多数派保写入可靠通过读写策略平衡实时性与性能适合分布式场景下的并发控制。
11 如何监控 Elasticsearch 集群状态通过 Kibana 监控 Elasticsearch。
你可以实时查看你的集群健康状态和性能也可以分析过去的集群、索引和节点指标
12 Elasticsearch 是否了解字典树简单说字典树就像一本按前缀排序的字典查词时顺着共同前缀快速定位这和 Elasticsearch 快速处理关键词、前缀搜索的需求高度契合。
13 Elasticsearch中的集群、节点、索引、文档、类型是什么集群由多台服务器节点组成的整体共同存储数据并提供联合查询能力用唯一名称标识默认 elasticsearch。
节点集群中的单台服务器负责存储数据和参与索引、搜索工作。
索引类似数据库如 MySQL 的 DB是存储相关数据的逻辑容器对应多个数据分片。
文档类似数据库表中的一行记录是最小数据单元可灵活定义字段但同字段建议类型一致。
类型索引内的逻辑分类类似表但在新版本 ES 中已被弱化逐渐被移除建议避免过度使用。
14 Elasticsearch中的倒排索引是什么苹果→[文档 1, 文档 2]手机→[文档 1]搜索 “苹果” 时直接通过倒排表定位到相关文档避免逐文档扫描大幅提升效率。
不是传统的:文章里有哪些关键字而是 关键字关联了哪些文章