做微服务做到第七天项目里已经有了注册中心、配置中心、网关这些基础设施服务之间的调用链路也跑通了。这时候会遇到一个很实际的业务问题商品列表页的搜索怎么做如果还用MySQL里的like %关键词%去硬查数据量到几十万条的时候响应就已经明显变慢更不用说分词、纠错、高亮这些搜索体验了。所以这一天我专门把Elasticsearch、Kibana和JavaRestClient这套组合完整过了一遍给微服务项目接上一个真正能打的搜索引擎。这套组合的定位很清晰Elasticsearch负责海量数据的存储和检索Kibana负责可视化和DSL语句调试JavaRestClient则是Java应用操作Elasticsearch的官方客户端。从环境搭建到索引建模从DSL查询到Java代码落地一条链路全部打通。这篇文章适合微服务初学者、打算在项目里集成搜索引擎的SpringBoot开发者以及那些已经装了Elasticsearch但不知道怎么写查询、怎么从Java里调用的朋友。我会把我在实战中踩过的坑和验证过的方案都写出来尽量让你跟着做就能跑通。1. 为什么要用Elasticsearch搜索引擎在微服务里的定位1.1 业务痛点MySQL做搜索为什么撑不住微服务项目做到一定阶段搜索功能一定会成为瓶颈这个瓶颈不是数据库容量不够而是查询方式不合适。MySQL的模糊查询用like %关键词%时即使字段建了索引也会失效因为前导通配符让B树没法有效二分查找只能全表扫描。数据量在十万以内可能还勉强能接受一旦到了百万级、千万级一个搜索接口的RT响应时间可能飙到两三秒这在前端体验上基本不可接受。还有一个更麻烦的问题用户搜索华为手机如果你在数据库里存的是HUAWEI Mate 60或者华为 畅享这种带空格或品牌别名的文本like查询是完全没有智能处理能力的。搜索系统需要分词、同义词扩展、拼音匹配、纠错提示这些能力这些都不是SQL能解决的。这就是Elasticsearch进入微服务体系的原因。ES本质上是一个基于倒排索引的分布式搜索引擎它天生就擅长处理搜索这个场景。在微服务架构里ES通常作为一个独立的搜索服务被拆分出来专门承担全文检索、聚合分析、日志查询这类任务。1.2 技术组合选型为什么是Elasticsearch Kibana JavaRestClient标题里这套组合不是随便选的每一层都有自己的职责。Elasticsearch是搜索引擎的核心引擎负责数据的写入、索引和检索Kibana是ES官方的可视化工具提供Web界面让我能直接在上面写DSL查询、查看索引状态、画图表JavaRestClient是Java语言操作ES的官方客户端应用代码就是通过它来跟ES通信的。为什么不用Spring Data Elasticsearch我在对比之后放弃了。Spring Data Elasticsearch封装程度高增删改查很方便但复杂的聚合、高亮、复杂bool查询封装的并不友好出了问题还不好排查。JavaRestClient是底层原生客户端DSL怎么写Java代码就怎么调语义完全一致调试起来非常直观也更容易理解ES本身的运作机制。微服务实战项目里我推荐用原生的JavaRestClient。ES 7.x 系列用的客户端是 RestHighLevelClientES 8.x 之后官方推出了新的 ElasticsearchClientAPI 变化比较大。我下面说的是基于 ES 7.17 RestHighLevelClient 的方案这也是目前微服务项目里用得最稳定、资料最多的一套。1.3 在微服务体系中ES承担的角色微服务把一个大系统拆成了多个独立部署的服务ES在这个架构里通常有两种落位方式一种是作为独立的搜索微服务对外提供统一搜索API内部封装索引管理、数据同步、查询逻辑另一种是作为公共基础组件被多个业务服务通过JavaRestClient直接访问。我比较推荐第一种方式。搜索逻辑单独收敛在一个服务里索引的创建、数据同步、查询调优都集中管理其他服务只关心搜索接口的入参出参不直接面对ES的复杂性。数据同步则可以通过SpringCloud的异步消息机制比如用Stream集成RabbitMQ或Kafka来做业务库里数据发生变化发送一条消息搜索服务消费消息后增量更新ES里的文档。这样ES和业务库之间就解耦了这也是微服务架构里ES最经典的落地姿势。2. Elasticsearch与Kibana环境搭建的完整流程2.1 版本选择与前置条件版本是第一个容易踩坑的地方。ES和Kibana的版本必须完全一致哪怕是7.17.0配7.17.1Kibana都可能启动不起来报版本不匹配错误。我在本地用的是7.17.7JDK要求11以上。这里有个细节ES 7.x发行包里自带了JDK在jdk目录下但如果你系统里的JAVA_HOME指向了低版本JDK启动时可能优先用了系统的JDK就会报错。所以前置条件第一件事就是检查JDK版本。可以用java -version确认。如果你本机装的是JDK8而项目其他部分必须用JDK8那也不用慌ES自带的jdk够用但要保证启动脚本实际使用的是ES自带的JDK而不是系统JAVA_HOME。Windows下可以在环境变量里把ES_HOME指向解压目录启动时用bin目录下的elasticsearch.bat它会优先找ES_JAVA_HOME。2.2 Windows下安装与启动Elasticsearch下载并解压ES压缩包后直接进到bin目录运行elasticsearch.bat。启动日志会刷出来一大片看到started字样就说明成功了。然后浏览器访问http://localhost:9200能看到一个JSON串{ name : DESKTOP-XXX, cluster_name : elasticsearch, version : { number : 7.17.7 } }这个JSON就是ES对外暴露的健康信息。name是节点名称cluster_name是集群名字都是默认值生产环境一定要改。默认配置下ES只绑定localhost不过本地开发够用了。修改核心配置在config/elasticsearch.yml里有几个参数建议第一次启动就配上cluster.name: my-application node.name: node-1 path.data: D:/dev/es-data path.logs: D:/dev/es-logs network.host: 127.0.0.1 http.port: 9200 discovery.type: single-node把discovery.type设置成single-node很重要。ES默认会尝试做集群发现单机模式下不设置这个参数节点会一直找不到其他节点启动后状态可能是yellow甚至是red。我们在本地学习阶段就是单节点直接声明single-node省掉一堆麻烦。还有个坑是路径里有空格或者中文ES启动可能报错。data和logs目录最好用纯英文路径而且要提前创建好。2.3 Kibana安装与连接Kibana的版本必须和ES一致解压后修改config/kibana.yml重点改两个配置server.port: 5601 elasticsearch.hosts: [http://localhost:9200]Kibana默认就是5601端口hosts指向ES地址。启动成功后访问http://localhost:5601看到登录页或者控制台界面就说明Kibana连上ES了。第一次进入会让你创建索引模式Index Pattern这个是可视化的前提但我们在Dev Tools工具里写DSL查询其实不需要先创建索引模式也能用。Kibana里最常用的其实是Dev Tools控制台点左侧菜单的Dev Tools进去后是一个代码编辑框可以直接写DSL查询、点运行箭头右边就是ES返回的结果。我在调试DSL语句时基本离不开这个界面因为能即时看到搜索结果和耗时详情比用Postman调ES接口直观得多。2.4 资源限制与常见启动问题ES对系统资源比较敏感尤其是内存。默认堆内存是1GB如果机器内存紧张会出现启动很慢、运行一会儿就OOM的情况。修改config/jvm.options文件里的-Xms和-Xmx建议设成一样的值避免运行期堆大小动态调整带来的性能损耗-Xms2g -Xmx2g如果机器只有4GB内存建议留1GB给系统JVM堆顶多给2GB再开启系统的swap或者直接不跑别的重量级服务。启动失败的另一个常见原因是端口被占用。9200端口被其他程序占了ES会启动失败。可以用netstat -ano | findstr 9200检查一下。如果是安装了其他搜索组件或者IDEA内置服务占用了换一个http.port端口也行但Kibana的hosts配置也要同步改。3. Elasticsearch核心概念与IK中文分词器3.1 索引、文档、映射与MySQL的类比学习ES最难的是把脑子里SQL那套概念转过来。我用一张表对照ElasticsearchMySQL说明Index索引Database数据库一个索引即一类数据的集合Type类型已废弃Table表ES 7.x已移除了多Type一个索引对应一种结构Document文档Row行一条JSON格式的数据Field字段Column列文档里的一个属性Mapping映射Schema表结构字段类型和分析规则的预定义在ES里一切都是JSON。比如一条商品数据{ title: 华为Mate60, price: 6999.00, category: 手机, brand: 华为 }一条数据就是一个文档。ES会自动给文档生成一个_id也可以在写入时指定业务id。它和MySQL最大的区别是ES里没有表结构强约束你可以往一个索引里写入结构完全不同的JSON但生产环境这么做会很乱所以要用Mapping预先定义好字段类型。3.2 倒排索引搜索引擎为什么快ES快的秘密在于倒排索引Inverted Index。MySQL的B树索引是文档到词语的正向结构检索时得遍历文档去匹配关键词倒排索引反过来先建立词语到文档的映射表。举个例子三篇文档标题分别包含华为手机、小米手机、华为电脑ES会把标题分词得到词条华为、手机、小米、电脑然后维护一张术语词典每个词条后面挂着一个文档列表。用户搜索华为时ES直接去词典里查华为O(1)就能找到包含它的文档完全不需要全表扫描。这就是为什么搜索性能和数据量基本不挂钩数据越多倒排索引的优势越明显。理解这一点后就能明白ES的搜索性能核心在于分词规则和索引结构而不在于数据库的优化技巧。分词得准倒排索引才有意义。这也是中文分词器如此重要的原因。3.3 IK分词器安装与配置ES自带的标准分词器对英文支持不错中文就不行了它会把中文按单字切分几乎没有语义。比如华为手机会被切成华、为、手、机搜索华为时根本匹配不到整词结果几乎不可用。解决方案是安装IK分词器ik-analysis插件它是国内用得最广的中文分词插件。安装步骤很简单1. 在IK分词器的GitHub仓库下载对应ES版本的zip包版本号必须与ES一致 2. 将zip内容解压到ES安装目录/plugins/ik/下 3. 重启Elasticsearch 4. 访问http://localhost:9200/_cat/plugins看到analysis-ik就说明安装成功重启后IK分词器提供两种分词模式ik_smart是做最粗粒度的拆分适合搜索关键词提取ik_max_word做最细粒度的拆分适合索引时尽可能多地切出词条。比如华为手机ik_smart分词结果华为手机ik_max_word分词结果华为、华为手机、手机实际IK还会切出华、为这种单字但会标注出来搜索时权重不同。实际使用时一般索引mapping里用ik_max_word搜索时用ik_smart这样既能尽可能多地建立词条又能保证查询结果精确。3.4 在Kibana里创建索引和映射索引要提前设计好Mapping不能等数据写进去再改因为分词规则一旦确立重新分词需要重建索引。在Kibana Dev Tools里创建一个商品索引PUT /products { mappings: { properties: { title: { type: text, analyzer: ik_max_word, search_analyzer: ik_smart }, price: { type: double }, category: { type: keyword }, brand: { type: keyword } } } }这里有个关键选择title用text类型并指定IK分词器因为标题需要全文搜索category和brand用keyword类型因为分类和品牌一般是精确匹配不需要分词。keyword类型和text类型的区别是keyword不会分词整串存储适合排序、聚合、精确匹配。如果产品名称字段设成keyword用户搜华为手机就搜索不到如果设成text按分类统计时又会得到奇怪的聚合结果。这个设计纠结需要在实际使用中逐步体会。写入一条测试数据PUT /products/_doc/1 { title: 华为Mate60手机, price: 6999.00, category: 手机, brand: 华为 }这里的_doc是类型占位符ES 7.x为兼容历史写法固定保留的。之后用GET /products/_search就能看到所有文档。4. 基于Kibana的DSL查询实战4.1 基础查询match_all、match、term和termsDSL查询是ES的核心交互语言用Kibana的Dev Tools调试效率极高。先说四个最基础的查询。match_all是查询所有文档语法是GET /products/_searchbody里写{query: {match_all: {}}}常用于测试连通性或者全量导出。match是分词匹配查询ES会对查询关键词做分词再匹配倒排索引。搜索华为手机时IK会切出华为、手机这两个词条文档中只要包含其中任意一个就会被查询到并按相关度打分排序GET /products/_search { query: { match: { title: 华为手机 } } }term是精确匹配查询不会对查询词做分词适合keyword类型字段。比如精确查品牌GET /products/_search { query: { term: { brand: 华为 } } }terms是term的复数版匹配多个精确值比如同时查华为和小米两个品牌GET /products/_search { query: { terms: { brand: [华为, 小米] } } }这里特别容易踩坑如果terms查的是text字段由于text字段被分词了term查华为手机这种整体词条时可能查不到因为索引里存的可能是华为和手机两个词条。所以精确匹配场景一定要把字段定义为keyword。4.2 复合查询bool组合多条件实际业务里的搜索条件往往不止一个比如价格区间、品牌过滤、关键词匹配同时出现。这时候用bool查询组合多个条件。bool里有几个关键词must必须满足参与相关度打分should满足其一即可可配合minimum_should_count控制最少满足数must_not必须不满足的逻辑相当于SQL里的NOTfilter过滤条件必须满足但不会参与打分性能更高商品搜索场景一个比较典型的组合查询GET /products/_search { query: { bool: { must: [ { match: { title: 手机 } } ], should: [ { term: { brand: 华为 } } ], filter: [ { range: { price: { lte: 8000 } } } ] } } }这个查询的意思是标题必须包含手机如果品牌是华为则加分价格不超过8000。filter里的range查询是范围过滤gte表示大于等于lte表示小于等于。把价格这类用range加在filter里而不是must里就是利用filter不计算分数的机制提升查询性能。4.3 聚合查询分组统计和指标统计聚合查询Aggregations是ES数据分析的核心相当于SQL里的GROUP BY和聚合函数。它分两类桶聚合bucket相当于分组指标聚合metric相当于求平均值、总和这类统计。按品牌分组统计商品数量的DSLGET /products/_search { size: 0, aggs: { brand_group: { terms: { field: brand, size: 10 } } } }size设为0表示不看搜索结果列表只关心聚合结果。brand_group是这个聚合的自定义名字terms是桶聚合类型上下文中能看到华为分组的数量为若干。再加一个指标聚合统计每个品牌下的平均价格GET /products/_search { size: 0, aggs: { brand_group: { terms: { field: brand, size: 10 }, aggs: { avg_price: { avg: { field: price } } } } } }这种嵌套聚合非常强大一个请求里就能把分组和统计一次拿到业务方不需要再把数据捞出来用代码二次加工。4.4 分页、排序与高亮搜索接口里除了查询条件还要关心返回格式。ES默认只返回前10条需要分页可以用from和size但要注意深分页性能很差这也是ES的一个经典问题。如果业务上确实需要跳页很深生产环境一般用search_after方式以后遇到再深入我先记下这里是坑。排序用sort字段按价格升序GET /products/_search { query: { match_all: {} }, sort: [ { price: { order: asc } } ], from: 0, size: 10 }高亮是在搜索结果中把匹配词用标签标记出来方便前端展示。ES通过highlight配置实现GET /products/_search { query: { match: { title: 华为手机 } }, highlight: { fields: { title: { pre_tags: [em], post_tags: [/em] } } } }返回结果里会多出一个highlight字段title里匹配到的词会被自动包上em标签前端加个样式就行。5. JavaRestClient实战从初始化到增删改查5.1 引入依赖和初始化客户端JavaRestClient的使用第一步是引入依赖。项目如果是SpringBoot直接把版本管理交给SpringBoot的dependencyManagement即可。我用的是7.17.7版本需要两个依赖dependency groupIdorg.elasticsearch.client/groupId artifactIdelasticsearch-rest-high-level-client/artifactId version7.17.7/version /dependency在SpringBoot项目里可以把客户端定义成Bean注入到需要的地方Configuration public class ElasticsearchConfig { Bean public RestHighLevelClient restHighLevelClient() { return new RestHighLevelClient( RestClient.builder( new HttpHost(localhost, 9200, http) ) ); } }注意RestHighLevelClient在ES 8.x版本已经被标记为废弃官方推荐用新的Java API Client。但8.x的API和7.x差异很大网上大部分生产案例仍是7.x。微服务项目若还没升级到ES 8用RestHighLevelClient是非常稳妥的选择。初始化完成后记得在应用关闭时调用client.close()释放连接资源SpringBoot的Bean的destroyMethod属性可以帮我处理。5.2 Java操作索引创建、删除与判断有了客户端第一步是索引层面的操作。创建索引时用CreateIndexRequest把之前Kibana里写的Mapping同步到Java代码里public void createProductIndex() throws IOException { CreateIndexRequest request new CreateIndexRequest(products); request.mapping({\n \properties\: {\n \title\: { \type\: \text\, \analyzer\: \ik_max_word\, \search_analyzer\: \ik_smart\ },\n \price\: { \type\: \double\ },\n \category\: { \type\: \keyword\ },\n \brand\: { \type\: \keyword\ }\n }\n }, XContentType.JSON); CreateIndexResponse response client.indices().create(request, RequestOptions.DEFAULT); boolean acknowledged response.isAcknowledged(); }判断索引是否存在用GetIndexRequestGetIndexRequest request new GetIndexRequest(products); boolean exists client.indices().exists(request, RequestOptions.DEFAULT);删除索引用DeleteIndexRequest注意这个操作不可逆真实生产环境删除索引前必须经过充分确认。5.3 文档的增删改查与批量操作索引操作是元数据层面的准备日常开发打交道最多的还是文档的CRUD。新增一条文档用IndexRequest可以手动指定id也可以让ES自动生成IndexRequest request new IndexRequest(products); request.id(1); request.source({\title\:\华为Mate60手机\,\price\:6999.00,\category\:\手机\,\brand\:\华为\}, XContentType.JSON); IndexResponse response client.index(request, RequestOptions.DEFAULT);按id查询文档GetRequest request new GetRequest(products, 1); GetResponse response client.get(request, RequestOptions.DEFAULT); String json response.getSourceAsString();修改文档最常用的是部分更新UpdateRequest只更新某些字段而保留其他字段UpdateRequest request new UpdateRequest(products, 1); request.doc({\price\: 8999.00}, XContentType.JSON); UpdateResponse response client.update(request, RequestOptions.DEFAULT);删除文档DeleteRequest request new DeleteRequest(products, 1); DeleteResponse response client.delete(request, RequestOptions.DEFAULT);批量操作是实际项目中的高性能利器。比如初始化数据时几万条数据要写入ES一条条调接口是低效的。用BulkRequest一次提交多个操作BulkRequest bulkRequest new BulkRequest(); for (Product product : productList) { IndexRequest request new IndexRequest(products); request.id(product.getId().toString()); request.source(productToJson(product), XContentType.JSON); bulkRequest.add(request); // 建议每批提交1000-2000条 if (bulkRequest.numberOfActions() 1000) { BulkResponse response client.bulk(bulkRequest, RequestOptions.DEFAULT); bulkRequest new BulkRequest(); } } // 提交最后一批 if (bulkRequest.numberOfActions() 0) { client.bulk(bulkRequest, RequestOptions.DEFAULT); }每批1000条左右是实践下来吞吐量和内存占用比较平衡的数值。如果单批太大ES的bulk性能反而可能下降因为单个请求体太重会触发服务端HTTP请求体大小限制。5.4 搜索查询的Java实现Java里做搜索用的是SearchRequest和SearchSourceBuilder这两个类的组合可以构建出和DSL几乎一一对应的查询。先看一个匹配查询SearchRequest searchRequest new SearchRequest(products); SearchSourceBuilder sourceBuilder new SearchSourceBuilder(); sourceBuilder.query(QueryBuilders.matchQuery(title, 华为手机)); sourceBuilder.from(0); sourceBuilder.size(10); searchRequest.source(sourceBuilder); SearchResponse response client.search(searchRequest, RequestOptions.DEFAULT); SearchHits hits response.getHits(); for (SearchHit hit : hits.getHits()) { String json hit.getSourceAsString(); System.out.println(json); }QueryBuilders类提供了所有DSL查询的Java方法基本上一一对应termQuery、rangeQuery、boolQuery等。bool查询的Java写法稍微多一点BoolQueryBuilder boolQuery QueryBuilders.boolQuery(); boolQuery.must(QueryBuilders.matchQuery(title, 手机)); boolQuery.should(QueryBuilders.termQuery(brand, 华为)); boolQuery.filter(QueryBuilders.rangeQuery(price).lte(8000)); sourceBuilder.query(boolQuery);聚合查询在Java里稍微绕一点但思路和DSL一致TermsAggregationBuilder aggregation AggregationBuilders.terms(brand_group).field(brand); sourceBuilder.aggregation(aggregation); sourceBuilder.size(0); SearchResponse response client.search(searchRequest, RequestOptions.DEFAULT); Terms brandGroup response.getAggregations().get(brand_group); for (Terms.Bucket bucket : brandGroup.getBuckets()) { String key bucket.getKeyAsString(); long docCount bucket.getDocCount(); }这种写法和DSL保持高度一致我在Kibana里验证好一条DSL之后照搬成Java代码基本不会出逻辑错误。5.5 高亮结果解析Java客户端里处理高亮需要在SearchSourceBuilder上配置高亮然后从SearchHit里取highlightFields。注意返回的不是一个普通字段而是Map结构HighlightBuilder highlightBuilder new HighlightBuilder(); highlightBuilder.field(title); highlightBuilder.preTags(em); highlightBuilder.postTags(/em); sourceBuilder.highlighter(highlightBuilder); SearchResponse response client.search(searchRequest, RequestOptions.DEFAULT); for (SearchHit hit : response.getHits().getHits()) { MapString, HighlightField highlightFields hit.getHighlightFields(); HighlightField titleField highlightFields.get(title); if (titleField ! null) { String highlightTitle Arrays.stream(titleField.fragments()) .map(Text::string) .collect(Collectors.joining()); System.out.println(highlightTitle); } }这一步在业务上很有用搜索结果里默认需求是展示高亮后的标题而不是原始标题。前端拿到带em标签的字符串后渲染出高亮效果用户能直观看到自己搜的关键词命中的位置。6. 常见问题与排查技巧实录6.1 安装启动阶段的问题Windows下最典型的启动失败是Java版本报错。启动脚本报could not find java in JAVA_HOME或者Unsupported major.minor十有八九是JAVA_HOME指向的JDK版本太低。前面提过ES自带JDK但我遇过一次环境变量里JAVA_HOME指到JDK8而ES需要JDK11启动直接失败。解决方式是设置ES_JAVA_HOME环境变量指向ES安装目录里的jdk这个变量优先于JAVA_HOME能精确控制ES使用的JDK。另一个高频问题启动过程中报bootstrap checks failed。ES默认绑定localhost时检查比较宽松一旦network.host改为非本机地址会触发bootstrap checks。常见报错是max virtual memory areas vm.max_map_count [65530] is too low这是Linux下的问题Windows上少见。Linux环境可以通过sysctl -w vm.max_map_count262144临时调整想永久生效就写入/etc/sysctl.conf。Windows下面倒是省心但如果装了360等安全软件可能会拦截ES写数据文件的请求启动时报权限异常。启动成功但访问不了9200先确认防火墙有没有放行。本地Windows防火墙在初次启动时通常会弹窗询问是否允许Java访问网络如果点了取消ES的HTTP端口就只对本机生效局域网其他机器访问不了。改法是在防火墙的高级设置里新增入站规则允许Java或者直接允许9200端口。6.2 连接超时与集群状态异常Kibana连不上ES最常见的提示是Kibana server is not ready yet。如果ES已经正常启动检查kibana.yml里的elasticsearch.hosts地址有没有写对。如果Kibana和ES在同一台机器用localhost没问题如果是跨机器部署这个地址必须是能访问的IP和端口。在浏览器里直接访问一下这个URL能返回ES的JSON串说明网络通问题在Kibana配置返回不了就先解决网络。Java客户端连接超时绝大多数情况是防火墙拦截了9200端口或者连了9300端口。9200是HTTP端口JavaRestClient走HTTP9300是ES节点间通信的TCP端口不要用在客户端连接上。我在一开始就见过有人把HttpHost的端口写成9300客户端初始化半天一执行请求就Connection refused。ES集群状态变yellow的经典原因是索引的分片副本没有分配。单节点学习时索引默认配置了1个分片1个副本副本只有一份且必须在不同节点上单节点分配不了副本所以状态变成yellow。这不是功能性错误数据可以正常读写但看到yellow总是心里不踏实。解决方式很简单创建索引时指定副本为0PUT /products { settings: { number_of_replicas: 0 } }或者等以后扩展到多节点集群副本会被自动分配。6.3 中文搜索结果不准与分词问题搜索结果不准先别急着怪ES几乎所有中文搜索问题都出在分词器上。装了IK之后新建的索引才会用到IK分词启动IK插件之前创建的旧索引仍然用的旧分词规则。我踩过最深的坑是先建了索引传了数据再装IK结果搜索还是按单字匹配一查发现索引的mapping里analyzer还是standard。解决办法就是删索引重建或者用_update_by_query重新索引一遍但重建索引会把数据也清掉生产环境需要借助reindex API迁移。另一个分词的坑是ik_max_word和ik_smart的选择。如果自定义词典没加载某些行业术语会被切得不合理。比如我搜索华为 Mate60的时候IK可能把字母和数字切到什么都不匹配。IK支持自定义词典在IK的config目录里编辑IKAnalyzer.cfg.xml配置ext_dict指向一个自定义词典文件比如?xml version1.0 encodingUTF-8? !DOCTYPE properties SYSTEM http://java.sun.com/dtd/properties.dtd properties commentIK Analyzer 扩展配置/comment entry keyext_dictcustom/mydict.dic/entry /properties在custom/mydict.dic里每行一个词比如Mate60保存后重启ES再次分词就能识别出来这些自定义词。6.4 数据写进去了查不到内容这种情况最让人头大文档明明写入成功返回result为created/updated但搜索时结果为空。我从头排查下来原因集中在两个第一查询词和索引内容不一致。比如文档里存的是HUAWEI Mate60用户搜华为手机IK分词后词条完全不同自然匹配不到。这不是技术问题是数据质量问题。强制搜索能查到的技巧是mapping里设置copy_to字段把品牌名、别名、中文名拼接成一个search_text字段统一搜索靠多字段冗余提升召回率这是ES搜索实战里非常常用的方案。第二match匹配的是text字段而term查询精确匹配keyword字段。搜索华为时用term查titletitle是text类型已经被分词成华为手机等词条这时term查整体词条华为是匹配不到倒排索引里的词条文档的。遇到这种情况一定先把字段类型搞明白再选择合适的查询方式。判断字段类型很简单Kibana里GET /products/_mapping就能看到。6.5 Java代码调试中的常见问题JavaRestClient的源码相对直观但有一类问题很隐蔽RequestOptions。每个client操作都要传RequestOptions.DEFAULT但如果ES配置了安全认证例如云上的ES或者生产环境开了X-Pack安全就必须在RequestOptions里加认证头否则所有API调用都会返回401。这部分我一开始忽略了调试了很久才发现是认证的问题。还有连接池相关问题。RestHighLevelClient内部基于Apache HttpClient连接数是有限的。如果并发高默认连接池不够用会出现一些奇怪的超时或连接拒绝报错。可以通过RestClientBuilder自定义连接参数RestClient.builder(new HttpHost(localhost, 9200, http)) .setHttpClientConfigCallback(builder - { builder.setMaxConnTotal(100); builder.setMaxConnPerRoute(50); return builder; })在实际微服务项目里搜索接口的QPS往往不低连接池配置需要偏离默认值。建议把连接总数和路由连接数调大配合下面说到的异步方式使用。6.6 性能优化经验异步调用与超时设置搜索接口如果放在微服务网关后面通常要求毫秒级响应。JavaRestClient本身是同步阻塞式的在SpringBoot里如果直接用controller线程调ES请求尖峰时线程会大量堆积。更好的做法是用JavaRestClient的异步客户端或者自己用线程池做隔离。RestHighLevelClient提供了异步版本比如searchAsyncclient.searchAsync(searchRequest, RequestOptions.DEFAULT, new ActionListenerSearchResponse() { Override public void onResponse(SearchResponse searchResponse) { // 成功回调 } Override public void onFailure(Exception e) { // 失败回调 } });异步回调语义在SpringBoot里配合CompletableFuture或者WebFlux用更顺畅。不过异步编程的复杂度高项目早期流量不大时同步够用。做异步要付出的心智成本跟业务量完全对等。微服务项目里的原则是先把功能跑对再优化性能。设置超时时间非常必要。默认情况下如果ES响应慢客户端会一直等下去。生产环境一般设置连接超时和读取超时RestClientBuilder builder RestClient.builder(new HttpHost(localhost, 9200, http)); builder.setRequestConfigCallback(requestConfigBuilder - requestConfigBuilder .setConnectTimeout(5000) .setSocketTimeout(10000) );我建议连接超时控制在3秒以内读取超时控制在10秒以内。ES的查询本身非常快如果超过这个阈值大概率是ES集群有压力或者查询写的有问题硬等下去没有意义尽早失败并降级才是微服务架构里的正确思路。把这些问题都趟完整个Elasticsearch01、Kibana、JavaRestClient这条链路就算是真正跑通了。我个人在实际操作中的体会是ES的技术栈表面看是工具安装和API调用内里其实是数据建模思路的转变。索引怎么建、字段用text还是keyword、分词器选哪种这些设计决策直接决定搜索效果的上限客户端代码反而是最不需要纠结的部分。只要把倒排索引和数据模型想清楚JavaRestClient的代码完全可以根据Kibana里验证好的DSL一句一句对出来。这也符合微服务学习的最佳路径先在可视化界面里把原理摸透再用代码去复现它。这次搭建好之后下一步可以把搜索能力抽成一个独立的微服务配合消息队列做数据同步再试试搜索提示、热词排行、聚合分析这些进阶玩法ES能发挥价值的地方还很多。
