1. 项目缘起与整体设计思路1.1 为什么要在Spring Boot里折腾ElasticSearch先说说这个项目的来龙去脉。手头有一个中等规模的业务系统数据量大概在千万级别用的是MySQL做主力存储。业务初期用LIKE %关键词%做模糊查询还能扛住但到了后面多字段组合检索、分词匹配、相关性排序这些需求一上来数据库直接顶不住慢查询日志一天能刷出几百兆。这时候摆在面前的路其实就两条要么上ElasticSearch要么硬扛着做分库分表加各种索引优化。权衡下来ES在全文检索和聚合分析上的天然优势太明显了尤其是它倒排索引的结构天生就是为搜索场景设计的。选Spring Boot整合ES核心原因是项目本身就是Spring Boot技术栈用spring-boot-starter-data-elasticsearch能省掉大量样板代码。但这里有个坑必须提前说清楚Spring Boot的版本和ES的版本是有严格对应关系的。ES 7.6.x这个版本对应的Spring Boot版本建议在2.3.x到2.4.x之间因为Spring Data Elasticsearch的版本迭代跟ES客户端协议绑定得很紧。我见过有人用Spring Boot 2.7去连ES 7.6结果启动就报method not found折腾半天才发现是版本不匹配。这个项目要解决的核心问题有三个第一把千万级商品数据的多字段检索响应时间从秒级压到百毫秒级第二支持中文分词和拼音搜索第三实现搜索关键词的高亮显示和聚合统计。适合有一定Spring Boot基础、正在被数据库搜索性能困扰的开发者参考小白也能跟着一步步搭起来但最好先了解下RESTful API的基本概念。1.2 整体架构与技术选型考量架构上我采用的是最经典的三层结构Controller层接收搜索请求Service层做业务逻辑和ES查询组装Repository层用Spring Data Elasticsearch的接口做数据访问。没有引入额外的中间件保持简单可控。技术选型这块几个关键决策点值得展开说客户端选择ES 7.6提供了两种Java客户端一种是RestHighLevelClient一种是新的ElasticsearchClient。我最终选了RestHighLevelClient原因是它在7.x版本里最成熟社区资料多而且Spring Data Elasticsearch 4.x默认就是基于它封装的。新的Java API Client虽然更现代但在7.6时期还不够稳定踩坑成本高。数据同步方案MySQL和ES之间的数据同步是个绕不开的问题。我评估了三种方案——双写、Logstash定时同步、Canal监听binlog。双写一致性最难保证Logstash有分钟级延迟Canal虽然实时但引入了额外组件。最终选了双写定时补偿的折中方案业务写入MySQL后异步发消息到ES同时每天凌晨跑一次全量校对任务把差异数据补上。这个方案实现简单对现有代码侵入小。分词器选择ES自带的standard分词器对中文就是按字切分搜手机会切成手和机效果很差。我用了IK分词器支持ik_smart和ik_max_word两种模式。ik_max_word切分更细适合索引阶段ik_smart切分粗一些适合搜索阶段。这个组合能显著提升召回率和准确率的平衡。提示IK分词器的版本必须和ES版本严格一致7.6.x的ES就要用7.6.x的IK版本不对会直接导致ES启动失败。2. 环境搭建与核心配置细节2.1 ES服务端安装与关键参数调优ES的安装本身不复杂但有几个参数不调好后面会吃大亏。我是在Linux环境下用tar包安装的没用Docker因为要调JVM参数和系统限制更方便。首先是JVM堆内存。ES默认给1GB这在生产环境肯定不够。我的经验是堆内存设置为物理内存的50%但不要超过31GB。为什么是31GB因为JVM在堆内存超过32GB时会关闭指针压缩反而浪费内存。我这边服务器是16GB内存所以jvm.options里设置-Xms8g -Xmx8g初始和最大堆设成一样避免运行时动态调整带来的性能抖动。其次是系统限制。ES对文件描述符和虚拟内存有要求需要在/etc/security/limits.conf里加上elasticsearch soft nofile 65536 elasticsearch hard nofile 65536 elasticsearch soft memlock unlimited elasticsearch hard memlock unlimited还有vm.max_map_count这个参数默认值太小会导致ES启动报错执行sysctl -w vm.max_map_count262144永久生效。分片和副本的设置也很关键。我建索引时设置number_of_shards3number_of_replicas1。分片数一旦设定就不能改除非reindex所以要根据数据量预估。经验公式是单个分片大小控制在30GB以内。我这边数据量大概50GB3个分片每个不到20GB比较合理。副本设1是为了高可用同时也能分担部分读请求。2.2 Spring Boot项目依赖与版本锁定依赖这块我强烈建议用dependencyManagement把版本锁死避免传递依赖带来的版本冲突。核心依赖就两个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-elasticsearch/artifactId /dependency dependency groupIdorg.elasticsearch.client/groupId artifactIdelasticsearch-rest-high-level-client/artifactId version7.6.2/version /dependency注意这里有个大坑spring-boot-starter-data-elasticsearch会传递依赖一个ES客户端版本如果这个版本和你服务端的ES版本不一致就会出现各种诡异的序列化错误。我的做法是在pom.xml里显式覆盖properties elasticsearch.version7.6.2/elasticsearch.version /properties这样Maven就会强制使用7.6.2的客户端。实测下来客户端和服务端版本一致是最稳的小版本号最好也完全对齐。配置文件application.yml里连接配置长这样spring: elasticsearch: rest: uris: http://127.0.0.1:9200 connection-timeout: 5000 read-timeout: 30000 username: elastic password: your_passwordread-timeout我设了30秒因为有些聚合查询确实慢设太短会频繁超时。但如果是纯搜索场景可以设短一点比如10秒快速失败反而有利于排查问题。2.3 实体类映射与索引结构设计Spring Data Elasticsearch用注解来做对象和索引的映射核心注解就几个Document标在类上指定索引名Id标在主键上Field标在字段上指定类型和分词器。我以商品搜索为例实体类大概是这样Document(indexName product_index, shards 3, replicas 1) public class ProductDoc { Id private Long id; Field(type FieldType.Text, analyzer ik_max_word, searchAnalyzer ik_smart) private String title; Field(type FieldType.Keyword) private String brand; Field(type FieldType.Double) private Double price; Field(type FieldType.Text, analyzer ik_max_word) private String description; Field(type FieldType.Date, format DateFormat.date_hour_minute_second) private Date createTime; }这里有几个设计决策要解释。title字段用了ik_max_word做索引分词ik_smart做搜索分词这是中文搜索的最佳实践——索引时切得细保证召回搜索时切得粗保证准确。brand字段用Keyword类型因为品牌名不需要分词精确匹配就行而且Keyword类型支持聚合。price用Double方便做范围查询和排序。注意Field注解里的analyzer和searchAnalyzer如果不指定默认用standard分词器中文场景下基本没法用一定要显式指定IK。索引的Mapping一旦创建字段类型就不能改了。所以前期设计时要考虑清楚哪些字段需要分词哪些需要聚合哪些需要排序。我踩过的坑是一开始把品牌字段设成了Text结果做品牌聚合时发现聚合出来的是分词后的碎片完全没法用只能删索引重建。3. 核心功能实现与实操过程3.1 索引初始化与数据批量导入索引初始化有两种方式一种是让Spring Data自动创建启动时根据注解生成另一种是手动用RestHighLevelClient创建。我推荐手动创建因为自动创建的Mapping往往不够精细比如IK分词器就不会自动配上。手动创建索引的代码大概这样public void createIndex() throws IOException { CreateIndexRequest request new CreateIndexRequest(product_index); request.settings(Settings.builder() .put(index.number_of_shards, 3) .put(index.number_of_replicas, 1) .put(index.refresh_interval, 1s)); MapString, Object title new HashMap(); title.put(type, text); title.put(analyzer, ik_max_word); title.put(search_analyzer, ik_smart); MapString, Object properties new HashMap(); properties.put(title, title); // ... 其他字段 MapString, Object mapping new HashMap(); mapping.put(properties, properties); request.mapping(mapping); client.indices().create(request, RequestOptions.DEFAULT); }refresh_interval设成1s是默认值意味着数据写入后1秒内可被搜索到。如果写入量特别大可以临时调大这个值比如30s等批量导入完再调回来能显著提升写入吞吐。数据批量导入用BulkRequest每批500到1000条比较合适。太小了网络开销大太大了内存压力大。我实测下来每批800条、并发4个线程导入100万数据大概花了3分钟。导入时要注意把refresh_interval设成-1关闭刷新导入完再改回来否则每次批量写入都触发refresh性能会差好几倍。3.2 多条件组合搜索的实现搜索功能是这个项目的核心。我用NativeSearchQueryBuilder来组装查询它比直接拼JSON更类型安全也更好维护。一个典型的多条件搜索场景用户输入关键词可以按品牌筛选按价格区间筛选还要分页和排序。代码结构如下BoolQueryBuilder boolQuery QueryBuilders.boolQuery(); // 关键词搜索title和description都要匹配 if (StringUtils.isNotBlank(keyword)) { boolQuery.must(QueryBuilders.multiMatchQuery(keyword, title, description) .type(MultiMatchQueryBuilder.Type.BEST_FIELDS) .tieBreaker(0.3f)); } // 品牌筛选 if (StringUtils.isNotBlank(brand)) { boolQuery.filter(QueryBuilders.termQuery(brand, brand)); } // 价格区间 if (minPrice ! null || maxPrice ! null) { RangeQueryBuilder rangeQuery QueryBuilders.rangeQuery(price); if (minPrice ! null) rangeQuery.gte(minPrice); if (maxPrice ! null) rangeQuery.lte(maxPrice); boolQuery.filter(rangeQuery); } NativeSearchQuery query new NativeSearchQueryBuilder() .withQuery(boolQuery) .withPageable(PageRequest.of(page, size)) .withSort(SortBuilders.fieldSort(createTime).order(SortOrder.DESC)) .build();这里的关键点是must和filter的区别。must里的查询会参与相关性打分filter里的不会但filter可以利用缓存性能更好。所以关键词搜索用must品牌和价格这种精确筛选用filter这是ES查询优化的基本原则。multiMatchQuery的BEST_FIELDS策略是指哪个字段匹配度最高就用哪个字段的分数。tieBreaker设0.3意思是其他匹配字段的分数按30%计入总分。这个参数调优需要根据实际数据测试0.3是个比较通用的起点。3.3 高亮显示与聚合统计高亮显示是搜索体验的重要一环。ES的高亮原理是在返回结果时把匹配到的关键词用指定标签包起来。配置如下HighlightBuilder highlightBuilder new HighlightBuilder(); highlightBuilder.field(title).preTags(em classhighlight).postTags(/em); highlightBuilder.field(description).preTags(em classhighlight).postTags(/em); highlightBuilder.fragmentSize(100).numberOfFragments(1); query.setHighlightQuery(new HighlightQuery(highlightBuilder));fragmentSize控制高亮片段的长度numberOfFragments控制返回几个片段。对于标题这种短字段可以设numberOfFragments(0)表示返回整个字段并高亮。聚合统计我用得最多的是品牌聚合和价格区间聚合。品牌聚合代码TermsAggregationBuilder brandAgg AggregationBuilders.terms(brand_agg) .field(brand) .size(20) .order(Terms.Order.count(false)); query.addAggregation(brandAgg);价格区间聚合用RangeAggregationBuilder可以自定义区间RangeAggregationBuilder priceAgg AggregationBuilders.range(price_agg) .field(price) .addRange(0, 100) .addRange(100, 500) .addRange(500, 1000) .addRange(1000, Double.MAX_VALUE);聚合结果的处理要注意Terms聚合返回的bucket是无序的需要自己按docCount排序。另外聚合字段必须是Keyword类型或者开启了fielddata否则会报错。这也是为什么前面强调品牌字段要用Keyword类型。3.4 数据同步的双写与补偿机制数据同步这块我的实现是业务代码在写完MySQL后通过Spring的ApplicationEventPublisher发一个事件监听器异步把数据写入ES。这样业务代码和ES写入解耦即使ES挂了也不影响主流程。// 业务代码 productMapper.insert(product); eventPublisher.publishEvent(new ProductSyncEvent(product.getId())); // 监听器 Async EventListener public void handleProductSync(ProductSyncEvent event) { try { Product product productMapper.selectById(event.getProductId()); ProductDoc doc convertToDoc(product); productRepository.save(doc); } catch (Exception e) { log.error(同步ES失败, productId{}, event.getProductId(), e); // 写入失败记录表等待补偿 syncFailMapper.insert(event.getProductId()); } }补偿机制是一个定时任务每天凌晨2点跑一次扫描失败记录表重新同步。另外还有一个全量校对任务每周跑一次对比MySQL和ES的文档数量差异超过阈值就告警。实操心得异步同步一定要加失败重试和记录否则数据不一致了你都不知道。我一开始没加失败记录结果有一次ES集群短暂不可用丢了几百条数据排查了半天才发现。4. 常见问题与排查技巧实录4.1 版本冲突与启动报错排查版本问题是新手最容易踩的坑。典型报错是java.lang.NoSuchMethodError或者ClassNotFoundException一看就是依赖冲突。排查方法是执行mvn dependency:tree | grep elasticsearch看看实际引入的客户端版本是多少。我遇到过一种情况项目里同时引入了spring-boot-starter-data-elasticsearch和某个第三方库后者传递依赖了一个低版本的ES客户端导致运行时加载了错误的类。解决办法是用exclusions把传递依赖排除掉显式声明正确版本。还有一种报错是Connection refused这个一般是ES服务没起来或者防火墙拦了9200端口。先用curl http://127.0.0.1:9200确认服务是否正常再检查Spring Boot配置的uris是否正确。如果是集群环境uris要写多个节点地址用逗号分隔。4.2 查询性能问题的定位与优化查询慢是最常见的问题。我的排查步骤是先用ES的profile API看查询在哪个阶段耗时最多然后针对性优化。GET /product_index/_search { profile: true, query: { ... } }常见的性能问题和对策我整理成了表格问题现象可能原因优化方案关键词搜索慢使用了wildcard或regexp查询改用match或term查询聚合慢聚合字段是Text类型改为Keyword类型或加fielddata深分页慢fromsize超过10000改用search_after排序慢排序字段没有doc_values确认字段类型支持排序写入慢refresh_interval太短批量导入时临时调大深分页这个问题特别典型。ES默认fromsize不能超过10000超过就报错。即使调大了index.max_result_window性能也会急剧下降因为每个分片都要返回fromsize条数据给协调节点。正确做法是用search_after基于上一页最后一条的排序值来查下一页。4.3 中文分词效果不佳的调优IK分词器虽然好用但默认词典不一定覆盖你的业务词汇。比如蓝牙耳机可能被切成蓝牙和耳机但如果你希望它作为一个整体就需要自定义词典。自定义词典的方法是在IK的config目录下新建custom.dic每行一个词然后在IKAnalyzer.cfg.xml里配置entry keyext_dictcustom.dic/entry改完要重启ES生效。另外IK还支持热更新词典配置一个远程URL就行但生产环境建议还是用本地文件加定时重启的方式更稳定。还有一个技巧是使用同义词。比如手机和移动电话是同义词用户搜手机时也应该能搜到标了移动电话的商品。同义词配置在synonym.txt里格式是手机,移动电话。同义词在索引和搜索阶段都可以用一般建议只在搜索阶段用避免索引膨胀。4.4 集群健康状态监控与告警ES集群的健康状态分三种green所有分片正常、yellow主分片正常副本分片未分配、red有主分片未分配。yellow状态在单节点环境下是正常的因为副本没法分配到同一个节点。但如果是多节点集群出现yellow就要检查是不是有节点掉线了。监控这块我用了ES自带的_cluster/health接口配合定时任务做告警ClusterHealthRequest request new ClusterHealthRequest(); ClusterHealthResponse response client.cluster().health(request, RequestOptions.DEFAULT); if (response.getStatus() ClusterHealthStatus.RED) { // 发告警 }除了健康状态还要关注几个关键指标JVM堆内存使用率超过75%要警惕、磁盘使用率超过85%ES会自动把索引设为只读、查询拒绝率thread_pool.search.rejected大于0说明线程池满了。这些指标可以通过_nodes/stats接口获取。避坑技巧ES的磁盘水位线默认是85%超过后索引会变成只读写入全部失败。我建议在80%就设置告警留出处理时间。清理数据可以用DELETE /index_name/_delete_by_query按时间删除老数据但要注意这个操作很耗资源最好在低峰期执行。5. 一些实操中的个人体会整个项目做下来最大的感受是ES用起来简单用好很难。入门可能一天就能跑通增删改查但要把搜索效果和性能调到理想状态需要反复测试和调优。我踩过最深的坑是Mapping设计。一开始图省事所有字符串字段都用Text结果聚合功能全废了只能删索引重建。所以前期一定要想清楚每个字段的用途要分词搜索的用Text要精确匹配和聚合的用Keyword两者都需要的就建两个字段一个Text一个Keyword用fields参数实现。另一个体会是不要迷信默认配置。ES的默认配置是通用场景的折中具体到你的业务分片数、副本数、刷新间隔、分词器这些都需要根据数据量和查询模式来调整。我建议在测试环境用真实数据压测观察各项指标再决定生产环境的配置。最后说个数据同步的小技巧。如果对实时性要求不高可以用Logstash做定时全量同步配置简单不用改业务代码。但如果要求秒级同步还是得走双写或者binlog监听的路子。我这边因为业务对实时性要求高选了双写但加了失败补偿兜底运行半年下来数据一致性没出过大问题。 
长河君 · 2026/10/16 7:28:18 · 阅读 1.2k Spring Boot整合ElasticSearch实战：千万级数据搜索优化与IK分词
1. 项目缘起与整体设计思路1.1 为什么要在Spring Boot里折腾ElasticSearch先说说这个项目的来龙去脉。手头有一个中等规模的业务系统数据量大概在千万级别用的是MySQL做主力存储。业务初期用LIKE %关键词%做模糊查询还能扛住但到了后面多字段组合检索、分词匹配、相关性排序这些需求一上来数据库直接顶不住慢查询日志一天能刷出几百兆。这时候摆在面前的路其实就两条要么上ElasticSearch要么硬扛着做分库分表加各种索引优化。权衡下来ES在全文检索和聚合分析上的天然优势太明显了尤其是它倒排索引的结构天生就是为搜索场景设计的。选Spring Boot整合ES核心原因是项目本身就是Spring Boot技术栈用spring-boot-starter-data-elasticsearch能省掉大量样板代码。但这里有个坑必须提前说清楚Spring Boot的版本和ES的版本是有严格对应关系的。ES 7.6.x这个版本对应的Spring Boot版本建议在2.3.x到2.4.x之间因为Spring Data Elasticsearch的版本迭代跟ES客户端协议绑定得很紧。我见过有人用Spring Boot 2.7去连ES 7.6结果启动就报method not found折腾半天才发现是版本不匹配。这个项目要解决的核心问题有三个第一把千万级商品数据的多字段检索响应时间从秒级压到百毫秒级第二支持中文分词和拼音搜索第三实现搜索关键词的高亮显示和聚合统计。适合有一定Spring Boot基础、正在被数据库搜索性能困扰的开发者参考小白也能跟着一步步搭起来但最好先了解下RESTful API的基本概念。1.2 整体架构与技术选型考量架构上我采用的是最经典的三层结构Controller层接收搜索请求Service层做业务逻辑和ES查询组装Repository层用Spring Data Elasticsearch的接口做数据访问。没有引入额外的中间件保持简单可控。技术选型这块几个关键决策点值得展开说客户端选择ES 7.6提供了两种Java客户端一种是RestHighLevelClient一种是新的ElasticsearchClient。我最终选了RestHighLevelClient原因是它在7.x版本里最成熟社区资料多而且Spring Data Elasticsearch 4.x默认就是基于它封装的。新的Java API Client虽然更现代但在7.6时期还不够稳定踩坑成本高。数据同步方案MySQL和ES之间的数据同步是个绕不开的问题。我评估了三种方案——双写、Logstash定时同步、Canal监听binlog。双写一致性最难保证Logstash有分钟级延迟Canal虽然实时但引入了额外组件。最终选了双写定时补偿的折中方案业务写入MySQL后异步发消息到ES同时每天凌晨跑一次全量校对任务把差异数据补上。这个方案实现简单对现有代码侵入小。分词器选择ES自带的standard分词器对中文就是按字切分搜手机会切成手和机效果很差。我用了IK分词器支持ik_smart和ik_max_word两种模式。ik_max_word切分更细适合索引阶段ik_smart切分粗一些适合搜索阶段。这个组合能显著提升召回率和准确率的平衡。提示IK分词器的版本必须和ES版本严格一致7.6.x的ES就要用7.6.x的IK版本不对会直接导致ES启动失败。2. 环境搭建与核心配置细节2.1 ES服务端安装与关键参数调优ES的安装本身不复杂但有几个参数不调好后面会吃大亏。我是在Linux环境下用tar包安装的没用Docker因为要调JVM参数和系统限制更方便。首先是JVM堆内存。ES默认给1GB这在生产环境肯定不够。我的经验是堆内存设置为物理内存的50%但不要超过31GB。为什么是31GB因为JVM在堆内存超过32GB时会关闭指针压缩反而浪费内存。我这边服务器是16GB内存所以jvm.options里设置-Xms8g -Xmx8g初始和最大堆设成一样避免运行时动态调整带来的性能抖动。其次是系统限制。ES对文件描述符和虚拟内存有要求需要在/etc/security/limits.conf里加上elasticsearch soft nofile 65536 elasticsearch hard nofile 65536 elasticsearch soft memlock unlimited elasticsearch hard memlock unlimited还有vm.max_map_count这个参数默认值太小会导致ES启动报错执行sysctl -w vm.max_map_count262144永久生效。分片和副本的设置也很关键。我建索引时设置number_of_shards3number_of_replicas1。分片数一旦设定就不能改除非reindex所以要根据数据量预估。经验公式是单个分片大小控制在30GB以内。我这边数据量大概50GB3个分片每个不到20GB比较合理。副本设1是为了高可用同时也能分担部分读请求。2.2 Spring Boot项目依赖与版本锁定依赖这块我强烈建议用dependencyManagement把版本锁死避免传递依赖带来的版本冲突。核心依赖就两个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-elasticsearch/artifactId /dependency dependency groupIdorg.elasticsearch.client/groupId artifactIdelasticsearch-rest-high-level-client/artifactId version7.6.2/version /dependency注意这里有个大坑spring-boot-starter-data-elasticsearch会传递依赖一个ES客户端版本如果这个版本和你服务端的ES版本不一致就会出现各种诡异的序列化错误。我的做法是在pom.xml里显式覆盖properties elasticsearch.version7.6.2/elasticsearch.version /properties这样Maven就会强制使用7.6.2的客户端。实测下来客户端和服务端版本一致是最稳的小版本号最好也完全对齐。配置文件application.yml里连接配置长这样spring: elasticsearch: rest: uris: http://127.0.0.1:9200 connection-timeout: 5000 read-timeout: 30000 username: elastic password: your_passwordread-timeout我设了30秒因为有些聚合查询确实慢设太短会频繁超时。但如果是纯搜索场景可以设短一点比如10秒快速失败反而有利于排查问题。2.3 实体类映射与索引结构设计Spring Data Elasticsearch用注解来做对象和索引的映射核心注解就几个Document标在类上指定索引名Id标在主键上Field标在字段上指定类型和分词器。我以商品搜索为例实体类大概是这样Document(indexName product_index, shards 3, replicas 1) public class ProductDoc { Id private Long id; Field(type FieldType.Text, analyzer ik_max_word, searchAnalyzer ik_smart) private String title; Field(type FieldType.Keyword) private String brand; Field(type FieldType.Double) private Double price; Field(type FieldType.Text, analyzer ik_max_word) private String description; Field(type FieldType.Date, format DateFormat.date_hour_minute_second) private Date createTime; }这里有几个设计决策要解释。title字段用了ik_max_word做索引分词ik_smart做搜索分词这是中文搜索的最佳实践——索引时切得细保证召回搜索时切得粗保证准确。brand字段用Keyword类型因为品牌名不需要分词精确匹配就行而且Keyword类型支持聚合。price用Double方便做范围查询和排序。注意Field注解里的analyzer和searchAnalyzer如果不指定默认用standard分词器中文场景下基本没法用一定要显式指定IK。索引的Mapping一旦创建字段类型就不能改了。所以前期设计时要考虑清楚哪些字段需要分词哪些需要聚合哪些需要排序。我踩过的坑是一开始把品牌字段设成了Text结果做品牌聚合时发现聚合出来的是分词后的碎片完全没法用只能删索引重建。3. 核心功能实现与实操过程3.1 索引初始化与数据批量导入索引初始化有两种方式一种是让Spring Data自动创建启动时根据注解生成另一种是手动用RestHighLevelClient创建。我推荐手动创建因为自动创建的Mapping往往不够精细比如IK分词器就不会自动配上。手动创建索引的代码大概这样public void createIndex() throws IOException { CreateIndexRequest request new CreateIndexRequest(product_index); request.settings(Settings.builder() .put(index.number_of_shards, 3) .put(index.number_of_replicas, 1) .put(index.refresh_interval, 1s)); MapString, Object title new HashMap(); title.put(type, text); title.put(analyzer, ik_max_word); title.put(search_analyzer, ik_smart); MapString, Object properties new HashMap(); properties.put(title, title); // ... 其他字段 MapString, Object mapping new HashMap(); mapping.put(properties, properties); request.mapping(mapping); client.indices().create(request, RequestOptions.DEFAULT); }refresh_interval设成1s是默认值意味着数据写入后1秒内可被搜索到。如果写入量特别大可以临时调大这个值比如30s等批量导入完再调回来能显著提升写入吞吐。数据批量导入用BulkRequest每批500到1000条比较合适。太小了网络开销大太大了内存压力大。我实测下来每批800条、并发4个线程导入100万数据大概花了3分钟。导入时要注意把refresh_interval设成-1关闭刷新导入完再改回来否则每次批量写入都触发refresh性能会差好几倍。3.2 多条件组合搜索的实现搜索功能是这个项目的核心。我用NativeSearchQueryBuilder来组装查询它比直接拼JSON更类型安全也更好维护。一个典型的多条件搜索场景用户输入关键词可以按品牌筛选按价格区间筛选还要分页和排序。代码结构如下BoolQueryBuilder boolQuery QueryBuilders.boolQuery(); // 关键词搜索title和description都要匹配 if (StringUtils.isNotBlank(keyword)) { boolQuery.must(QueryBuilders.multiMatchQuery(keyword, title, description) .type(MultiMatchQueryBuilder.Type.BEST_FIELDS) .tieBreaker(0.3f)); } // 品牌筛选 if (StringUtils.isNotBlank(brand)) { boolQuery.filter(QueryBuilders.termQuery(brand, brand)); } // 价格区间 if (minPrice ! null || maxPrice ! null) { RangeQueryBuilder rangeQuery QueryBuilders.rangeQuery(price); if (minPrice ! null) rangeQuery.gte(minPrice); if (maxPrice ! null) rangeQuery.lte(maxPrice); boolQuery.filter(rangeQuery); } NativeSearchQuery query new NativeSearchQueryBuilder() .withQuery(boolQuery) .withPageable(PageRequest.of(page, size)) .withSort(SortBuilders.fieldSort(createTime).order(SortOrder.DESC)) .build();这里的关键点是must和filter的区别。must里的查询会参与相关性打分filter里的不会但filter可以利用缓存性能更好。所以关键词搜索用must品牌和价格这种精确筛选用filter这是ES查询优化的基本原则。multiMatchQuery的BEST_FIELDS策略是指哪个字段匹配度最高就用哪个字段的分数。tieBreaker设0.3意思是其他匹配字段的分数按30%计入总分。这个参数调优需要根据实际数据测试0.3是个比较通用的起点。3.3 高亮显示与聚合统计高亮显示是搜索体验的重要一环。ES的高亮原理是在返回结果时把匹配到的关键词用指定标签包起来。配置如下HighlightBuilder highlightBuilder new HighlightBuilder(); highlightBuilder.field(title).preTags(em classhighlight).postTags(/em); highlightBuilder.field(description).preTags(em classhighlight).postTags(/em); highlightBuilder.fragmentSize(100).numberOfFragments(1); query.setHighlightQuery(new HighlightQuery(highlightBuilder));fragmentSize控制高亮片段的长度numberOfFragments控制返回几个片段。对于标题这种短字段可以设numberOfFragments(0)表示返回整个字段并高亮。聚合统计我用得最多的是品牌聚合和价格区间聚合。品牌聚合代码TermsAggregationBuilder brandAgg AggregationBuilders.terms(brand_agg) .field(brand) .size(20) .order(Terms.Order.count(false)); query.addAggregation(brandAgg);价格区间聚合用RangeAggregationBuilder可以自定义区间RangeAggregationBuilder priceAgg AggregationBuilders.range(price_agg) .field(price) .addRange(0, 100) .addRange(100, 500) .addRange(500, 1000) .addRange(1000, Double.MAX_VALUE);聚合结果的处理要注意Terms聚合返回的bucket是无序的需要自己按docCount排序。另外聚合字段必须是Keyword类型或者开启了fielddata否则会报错。这也是为什么前面强调品牌字段要用Keyword类型。3.4 数据同步的双写与补偿机制数据同步这块我的实现是业务代码在写完MySQL后通过Spring的ApplicationEventPublisher发一个事件监听器异步把数据写入ES。这样业务代码和ES写入解耦即使ES挂了也不影响主流程。// 业务代码 productMapper.insert(product); eventPublisher.publishEvent(new ProductSyncEvent(product.getId())); // 监听器 Async EventListener public void handleProductSync(ProductSyncEvent event) { try { Product product productMapper.selectById(event.getProductId()); ProductDoc doc convertToDoc(product); productRepository.save(doc); } catch (Exception e) { log.error(同步ES失败, productId{}, event.getProductId(), e); // 写入失败记录表等待补偿 syncFailMapper.insert(event.getProductId()); } }补偿机制是一个定时任务每天凌晨2点跑一次扫描失败记录表重新同步。另外还有一个全量校对任务每周跑一次对比MySQL和ES的文档数量差异超过阈值就告警。实操心得异步同步一定要加失败重试和记录否则数据不一致了你都不知道。我一开始没加失败记录结果有一次ES集群短暂不可用丢了几百条数据排查了半天才发现。4. 常见问题与排查技巧实录4.1 版本冲突与启动报错排查版本问题是新手最容易踩的坑。典型报错是java.lang.NoSuchMethodError或者ClassNotFoundException一看就是依赖冲突。排查方法是执行mvn dependency:tree | grep elasticsearch看看实际引入的客户端版本是多少。我遇到过一种情况项目里同时引入了spring-boot-starter-data-elasticsearch和某个第三方库后者传递依赖了一个低版本的ES客户端导致运行时加载了错误的类。解决办法是用exclusions把传递依赖排除掉显式声明正确版本。还有一种报错是Connection refused这个一般是ES服务没起来或者防火墙拦了9200端口。先用curl http://127.0.0.1:9200确认服务是否正常再检查Spring Boot配置的uris是否正确。如果是集群环境uris要写多个节点地址用逗号分隔。4.2 查询性能问题的定位与优化查询慢是最常见的问题。我的排查步骤是先用ES的profile API看查询在哪个阶段耗时最多然后针对性优化。GET /product_index/_search { profile: true, query: { ... } }常见的性能问题和对策我整理成了表格问题现象可能原因优化方案关键词搜索慢使用了wildcard或regexp查询改用match或term查询聚合慢聚合字段是Text类型改为Keyword类型或加fielddata深分页慢fromsize超过10000改用search_after排序慢排序字段没有doc_values确认字段类型支持排序写入慢refresh_interval太短批量导入时临时调大深分页这个问题特别典型。ES默认fromsize不能超过10000超过就报错。即使调大了index.max_result_window性能也会急剧下降因为每个分片都要返回fromsize条数据给协调节点。正确做法是用search_after基于上一页最后一条的排序值来查下一页。4.3 中文分词效果不佳的调优IK分词器虽然好用但默认词典不一定覆盖你的业务词汇。比如蓝牙耳机可能被切成蓝牙和耳机但如果你希望它作为一个整体就需要自定义词典。自定义词典的方法是在IK的config目录下新建custom.dic每行一个词然后在IKAnalyzer.cfg.xml里配置entry keyext_dictcustom.dic/entry改完要重启ES生效。另外IK还支持热更新词典配置一个远程URL就行但生产环境建议还是用本地文件加定时重启的方式更稳定。还有一个技巧是使用同义词。比如手机和移动电话是同义词用户搜手机时也应该能搜到标了移动电话的商品。同义词配置在synonym.txt里格式是手机,移动电话。同义词在索引和搜索阶段都可以用一般建议只在搜索阶段用避免索引膨胀。4.4 集群健康状态监控与告警ES集群的健康状态分三种green所有分片正常、yellow主分片正常副本分片未分配、red有主分片未分配。yellow状态在单节点环境下是正常的因为副本没法分配到同一个节点。但如果是多节点集群出现yellow就要检查是不是有节点掉线了。监控这块我用了ES自带的_cluster/health接口配合定时任务做告警ClusterHealthRequest request new ClusterHealthRequest(); ClusterHealthResponse response client.cluster().health(request, RequestOptions.DEFAULT); if (response.getStatus() ClusterHealthStatus.RED) { // 发告警 }除了健康状态还要关注几个关键指标JVM堆内存使用率超过75%要警惕、磁盘使用率超过85%ES会自动把索引设为只读、查询拒绝率thread_pool.search.rejected大于0说明线程池满了。这些指标可以通过_nodes/stats接口获取。避坑技巧ES的磁盘水位线默认是85%超过后索引会变成只读写入全部失败。我建议在80%就设置告警留出处理时间。清理数据可以用DELETE /index_name/_delete_by_query按时间删除老数据但要注意这个操作很耗资源最好在低峰期执行。5. 一些实操中的个人体会整个项目做下来最大的感受是ES用起来简单用好很难。入门可能一天就能跑通增删改查但要把搜索效果和性能调到理想状态需要反复测试和调优。我踩过最深的坑是Mapping设计。一开始图省事所有字符串字段都用Text结果聚合功能全废了只能删索引重建。所以前期一定要想清楚每个字段的用途要分词搜索的用Text要精确匹配和聚合的用Keyword两者都需要的就建两个字段一个Text一个Keyword用fields参数实现。另一个体会是不要迷信默认配置。ES的默认配置是通用场景的折中具体到你的业务分片数、副本数、刷新间隔、分词器这些都需要根据数据量和查询模式来调整。我建议在测试环境用真实数据压测观察各项指标再决定生产环境的配置。最后说个数据同步的小技巧。如果对实时性要求不高可以用Logstash做定时全量同步配置简单不用改业务代码。但如果要求秒级同步还是得走双写或者binlog监听的路子。我这边因为业务对实时性要求高选了双写但加了失败补偿兜底运行半年下来数据一致性没出过大问题。