100万并发这个数字，第一次听确实唬人。但做系统设计的第一件事，就是把“100万并发”这种抽象数字，翻译成具体的技术动作。这不是语文题，是算术题。你需要知道这100万是什么类型的请求、从哪来、到哪去，然后才能谈怎么设计系统。这里说句大实话：没有任何一个单点系统能扛住100万QPS，所谓高并发设计，本质上是把流量拆开、摊平、削峰、填谷，让每一层都只承担自己该承担的那部分压力。商品搜索系统尤其典型，因为它是典型的读多写少场景，用户点一下搜索，后端可能要查缓存、查索引、查商品详情、做排序、做过滤，链路很长，任何一个环节成了瓶颈，整个搜索体验就崩了。

这篇文章我会从整体设计思路、流量入口、缓存层、搜索引擎层、数据同步链路、降级兜底、常见问题几个维度完整拆解，把我这些年做搜索系统踩过的坑和沉淀下来的方案都摊开讲。不管你是准备面试，还是真的要动手搭一套支撑高并发搜索的系统，这篇都能给你一个可以直接照着做的完整蓝图。

1. 先把“100万并发”翻译成系统指标

在画架构图之前，先做一道算术题。假设线上业务确实有100万QPS的请求量，但这里有个常见误区：这100万请求不可能全是搜索请求。用户端的行为分布一般是浏览商品、加购、下单、支付占比更高，搜索请求占整体请求量的20%到30%就算很高了。也就是说，真正打到搜索系统的QPS大概在20万到30万。这个数字依然很大，但已经不是一个让人绝望的量级。

再往下拆，这20万到30万的搜索QPS，也并不是全部都打到搜索引擎。系统设计的一个核心原则就是“每一层都拦截一批流量”。用户发起搜索请求后，第一层是网关和负载均衡，第二层是搜索接口服务，第三层才是搜索引擎（比如Elasticsearch）。搜索接口服务会把结果缓存起来，热门关键词比如“手机”、“连衣裙”、“蓝牙耳机”这种，搜索结果大概率可以直接从缓存返回，根本不需要到搜索引擎走一遍。我做过的一个真实项目里，搜索接口加了Redis缓存之后，实际命中搜索引擎的流量只有总QPS的20%不到。

做系统设计的时候，我习惯先把QPS指标换算成更具体的东西：每台机器能扛多少并发，需要多少台机器，每条查询链路平均延迟要控制在多少毫秒以内，缓存命中率要做到多少以上。这些指标定下来，架构自然就清晰了。我一般按下面这个表格做容量预估：

这套数字从100万一路砍到几万，每砍一层，系统的成本和复杂度都会降一个台阶。这也是为什么我一直强调，高并发系统设计的第一课不是画图，而是先把流量模型算清楚。你连请求长什么样、流量分布如何都不知道，画出来的架构全是纸上谈兵。

2. 商品搜索系统的整体架构设计思路

2.1 核心设计原则：读多写少，缓存为王

商品搜索系统是所有高并发场景里最典型的一种，因为它几乎全是读操作。商品数据的变化频率不高，可能一天只更新几次，但用户的搜索请求是持续不断的。这意味着你完全可以把大量流量拦截在数据库之外，用缓存和搜索引擎构建一条高效的只读链路。

MySQL在这套链路里只承担两个职责：一是商品数据的持久化存储，二是索引重建时提供全量数据源。用户的每一次搜索请求都不应该直接打到MySQL，否则100万并发会立刻把数据库打挂。MySQL的并发上限一般在几千到一万左右，你用它扛几万的查询必然雪崩。正确做法是让它只处理每秒几百次的写入和少量的数据补偿查询，其他所有读流量都交给上层的Redis和Elasticsearch。

2.2 整体链路架构：六层分流模型

我设计商品搜索系统时，内部一直沿用六层分流的思路。这个思路不复杂，核心就是让每一层只干一件事，流量逐层收窄。

第一层是流量入口层，用LVS加Nginx集群做负载均衡和反向代理，负责把请求均匀分发到后端的搜索接口服务，同时承担一些基础的限流、黑白名单拦截。第二层是搜索接口服务层，也就是我们写的业务代码，负责参数校验、搜索词预处理、缓存查询、结果组装和兜底逻辑。第三层是Redis缓存层，负责缓存热门搜索词的结果、搜索热词、商品详情快照。第四层是Elasticsearch搜索引擎层，负责真正的全文检索、分词匹配、多字段过滤、排序打分。第五层是商品详情服务，负责从MySQL或其他存储中读取商品全量信息，这一层在搜索链路里通常是批量调用，不会单条实时查询。第六层是索引构建链路，MySQL的binlog通过Canal和Kafka异步同步到Elasticsearch，保证搜索数据与线上数据最终一致。

这张图里最关键的是第三和第四层的关系。我之前遇到过不少团队，一开始就没设计缓存层，所有搜索词都直接打到ES，结果ES集群规模急剧膨胀，硬件成本翻了好几倍，查询延迟还居高不下。加了缓存之后，同样的流量，ES的写入和查询压力都降低了七八成，整个系统的稳定性和成本都得到了很大的改善。

2.3 为什么选择Elasticsearch而不是MySQL模糊查询

这是搜索系统设计里最常被问的一个问题。商品搜索最核心的是对商品名称、类目、属性做全文检索，还需要支持分词、拼音、同义词扩展、错误纠正、按销量价格排序。MySQL的LIKE查询最大的问题是无法有效利用索引，一旦数据量到了千万级别，全表扫描的耗时直接奔着秒级去。当年MySQL 5.7加入全文索引，效果依然不够理想，对亿级别数据量的搜索场景基本无能为力。

Elasticsearch的底层是基于倒排索引打造的，天生就是为了处理“用关键词找文档”这种场景。它把每个词条映射到包含它的文档列表，查询的时候直接定位词条，然后合并文档列表，速度从分钟级提升到了毫秒级。再加上分片机制可以把数据分散到多台机器上并行查询，水平扩展性非常好。我做的搜索系统里，ES单集群承载了几亿的文档量，查询P99依然可以控制在50毫秒以内，这个量级MySQL几乎不可能做到。

当然，ES也不是银弹。它解决的是检索问题，而不是数据一致性问题。真正要保证商品数据不丢、不重复、顺序一致，还需要一套成熟的数据同步机制，这部分我会在后面的索引构建章节详细展开。

3. 流量入口与网关层：第一道防洪堤

3.1 LVS+Nginx的部署结构与关键参数

流量入口是整个系统的第一道防线，也是流量的命门。100万QPS的请求如果直接打到业务服务上，任何应用服务器都会瞬间被打爆。我的标准做法是使用LVS做四层负载均衡，后面挂Nginx集群做七层反向代理。

LVS工作在内核态，转发能力非常强悍，一台普通的服务器就能支撑几十万甚至上百万的并发连接，而且没有太多可调的东西，基本上就是配置虚拟IP和转发规则。Nginx则承担更细粒度的任务：HTTP协议解析、URL路由、限流控制、静态资源缓存、gzip压缩。Nginx的性能上限一般是一台机器8万到10万QPS，配合多核CPU和高性能调优，可以把这个数值稳定在比较理想的水平。

Nginx有几个关键参数值得留意。worker_processes建议设置为CPU核心数，不要盲目加大，多了反而因为上下文切换开销导致性能下降。worker_connections设置每个worker进程能同时保持的最大连接数，一般按65535配置。keepalive_timeout建议设置在15秒到30秒之间，可以显著降低每个连接的握手开销，提升长连接利用率。还有keepalive_requests，控制单个长连接上最多处理多少个请求，建议设置成1000左右，避免连接被某个客户端长时间占用。

我见过不少团队，Nginx部署完之后不做任何调优，直接用默认配置扛高并发，结果性能直接打了个五折。默认配置往往偏保守，很多参数是按照最低兼容标准设置的，用在高并发生产环境里会明显成为瓶颈。

3.2 限流策略：令牌桶与漏桶的选型

网关层除了分流，还有一个核心任务就是限流。高并发系统的容错设计里，限流永远是排在第一位的手段。当流量超过系统承载能力时，必须有意识地把一部分请求挡在门外，保证大部分用户可以正常使用。

我常用的限流方案有两种。第一种是令牌桶算法，系统的令牌以固定速率生成，请求来了先取令牌，拿到令牌才能继续往下走，拿不到就直接拒绝或者排队。这个算法的优势是允许一定的突发流量，因为桶里预存的令牌可以在瞬间消耗掉一部分。第二种是漏桶算法，请求像一个固定速率的水滴一样从桶里流出，不管上游来多少流量，下游收到的都是匀速的。漏桶的优势是保护下游更彻底，但会牺牲一些突发流量的体验。

商品搜索场景我推荐令牌桶。因为用户的搜索请求天然有波峰波谷，比如大促开始的前几分钟，搜索量会瞬间暴涨到平时的好几倍。如果服务器端用漏桶，整个系统会有大量请求排队等待，用户体验非常差。用令牌桶的话，桶里预存的令牌数量可以设置成平时流量的两到三倍，这样既能平滑掉一部分压力，又能保证突发流量不至于全部被拒。

具体到落地，如果只在一台Nginx上做单机限流，同一个用户可能被不同的Nginx节点处理，限流的边界就模糊了。我的建议是网关层做单机限流，Redis做分布式限流兜底。单机限流处理的是单台机器的保护，分布式限流控制的是整个集群的流量总量。两层配合，既能防单点打挂，又能防整体超载。限流阈值也不是拍脑袋定的，需要按照系统的压测数据进行标定，我会在后面的压测章节详细讲。

4. Redis缓存层：让搜索快如闪电的核心

4.1 缓存什么、缓存多久：缓存策略的确定

商品搜索系统里，Redis的定位是“第一道业务缓存”。它的作用不是让数据存更久，而是让热点数据离用户更近。搜索接口收到一个关键词之后，第一步不是去ES查询，而是先在Redis里查一下这个关键词的搜索结果是否已经被缓存了。如果命中，直接返回，整个过程的耗时通常在10毫秒以内。如果没命中，才去ES查询，然后把结果写入Redis，并设置一个合理的过期时间。

缓存的内容要区分场景。对于搜索结果这种聚合数据，我一般把商品ID列表、总命中数、分页信息序列化存成JSON或者Protobuf，key的设计规则是search:result:{keyword}:{page}:{pageSize}。意思是同一个关键词、同一页、同一页大小的请求会命中同一条缓存。对于热搜词列表，key设计成search:hot:day:{yyyyMMdd}，每天一份，用于支撑搜索框下面的热门推荐。

过期时间也需要谨慎设计。太短了，缓存效果不明显；太长了，用户看到的搜索结果可能和最新的库存、价格脱节。我通常会把基础过期时间设置在5到10分钟，同时加上一个随机偏移量，比如在5到10分钟之间随机浮动，避免同一个时间点大量key同时过期形成缓存雪崩。这个随机偏移量的作用，后面讲雪崩时还会再次提到。

4.2 缓存穿透、击穿、雪崩三板斧

高并发缓存场景绕不开“三座大山”：缓存穿透、缓存击穿、缓存雪崩。这三个问题做搜索系统的时候全部都会遇到，而且每一个都能把系统打挂。

缓存穿透是指查询一个必然不存在的数据，比如用户搜索一个根本不存在的商品词“哈哈哈哈不存在的商品”，缓存里没有，数据库里也没有，每次请求都会穿透到ES和数据库，导致后端压力陡增。解决思路有两个：一是对空结果也做缓存，把不存在的key缓存在Redis里，设置一个较短的过期时间比如60秒，这样重复的穿透请求就被拦截了。二是使用布隆过滤器，把所有可能的商品ID都存进布隆过滤器中，查询之前先判断key是否存在，不存在直接返回，连Redis都不需要查。

缓存击穿是指某个热点key在缓存过期的瞬间，有大量请求同时打到后端。比如某个爆款商品的搜索结果缓存刚好失效，刚好那几秒又有几万个用户搜索这个商品，ES就会瞬间收到几万条重复的查询请求。解决办法是使用互斥锁，缓存过期时只有一个请求能拿到锁去ES查询，其他请求等待锁释放后直接读取缓存。还有一种思路是使用逻辑过期时间，即缓存中存储一个逻辑过期时间戳，请求发现逻辑过期后，先返回旧数据，同时发起异步线程去ES刷新缓存，这种方式对用户体验更友好，代价是实现稍复杂。

缓存雪崩是指大量热点key在同一时间段集体过期，导致后端压力瞬间暴增。解决办法就是我在前面提到的过期时间加随机值，让key的过期时间自然分散开，不形成集中过期的效应。

4.3 热Key问题的四种解法

高并发搜索系统还有一个非常折磨人的问题：热Key。比如“618”、“双11”、“iPhone”这种关键词，一天几十万的搜索量，全部集中在同一个Key上，单台Redis的压力会非常大。Redis是单线程的，热点Key意味着这个Key上的所有操作都在同一个CPU核心上串行执行，其他键值对的访问都会受到影响。

我常用的解法有四种。第一种是本地缓存，在搜索接口服务的JVM里使用Caffeine缓存热点数据，设置一个很短的生命周期，比如5秒，请求到了接口层先查本地缓存，大幅减少对Redis的访问。第二种是Redis集群读写分离，给热Key所在的Redis节点增加从节点，把读请求分散到多个副本上。第三种是Key拆分，把热Key的value拆成多个子Key，比如一个热词的搜索结果拆成10份，请求进来按照某种哈希规则分散到不同的子Key上，压力就摊平了。第四种是给热Key设置较长的TTL，让它尽可能少地进入过期重建的流程。

这四种方案不是互斥的，实际使用中往往需要组合。我的常用组合是“本地缓存+Key拆分”，本地缓存解决单点压力，Key拆分解决单个Redis实例的读写瓶颈。热Key检测也要做成自动化的，通过Redis的monitor命令或者业务埋点监控来识别哪些Key的访问频率异常高，然后自动触发本地缓存策略，而不是纯靠人工每天盯监控。

5. 搜索引擎层：Elasticsearch集群的设计与调优

5.1 集群规模与分片设计

Elasticsearch是搜索系统的真正心脏。它扛下了所有的全文检索、分词匹配、多条件过滤和排序操作。ES集群设计得好不好，直接决定搜索结果的质量和响应速度。

先聊集群规模。假设我们承载的是几亿商品文档，每个文档0.5KB到2KB不等，总数据量大概在几十GB到几百GB之间。这个数据量对ES来说不算大，瓶颈主要在于查询并发。4到6万QPS的查询压力下，我建议至少准备三台数据节点，每台配置32核CPU和128GB内存，同时搭配两台专做协调和主节点的机器。数据节点负责存储和查询计算，主节点负责集群管理、分片分配、元数据维护，职责要分开。

分片的设计是ES调优里的重头戏。分片数量过少，单个分片的数据量过大，查询的并发能力受限。分片数量过多，每个分片都需要一层查询开销，集群管理的负担也会加重。我一般按单个分片不超过30GB到50GB的标准来估算分片总数，再乘以一个冗余系数。比如总数据量300GB，按单分片40GB计算，主分片数量在7到8个左右，加一个副本，那总分片数量就在15个左右。分片数量一旦确定，建索引之后不建议随意修改，因为重新分片意味着全量数据迁移，生产环境代价很大。

5.2 倒排索引的工作原理与Mapping设计

ES的底层是倒排索引。说通俗一点，正排索引是“文档到词”的映射，倒排索引是“词到文档”的映射。给“红色连衣裙”这个词做查询时，ES会先分词，得到“红色”、“连衣裙”这些词项，然后去倒排索引中查找每个词项对应的文档列表，再做集合运算取出包含这些词的文档，最后按相关性打分排序返回。

这个机制带来一个好处：查询速度不随文档数量的增长而线性恶化。因为词项词典本身是排好序的，可以通过跳表、FST（有限状态转换器）高效定位，文档列表的合并也做了大量优化。这也是ES能支撑亿级数据毫秒级响应的核心原因。

Mapping设计对搜索效果的影响非常大。我的经验是，商品名称使用text类型，开启分词器，用于全文检索。商品ID、类目ID、品牌ID使用keyword类型，用于精确过滤。价格、库存这类需要范围查询的字段，使用integer或者long类型。规格参数这类字段多、结构不固定的数据，使用nested类型或者flattened类型，但要慎重，nested查询性能开销较大。对于不需要参与检索的字段，比如商家内部备注、运营备注，直接设置为enabled:false，不建索引，省存储省性能。

5.3 查询性能优化的六个实战要点

ES查询性能优化是搜索系统调优的重头戏。我总结了自己实际项目中验证过的六个有效手段。

第一，尽可能使用filter context而非query context。filter只做过滤不参与相关性打分，ES会对filter的结果做缓存，下次同样的过滤条件会直接走缓存，性能提升明显。价格过滤、库存过滤、类目过滤都应该用filter。

第二，合理使用search_after替代深分页。ES的from+size分页有一个致命问题：深分页时，每个分片都要把前N条数据全部取出来再聚合排序，数据量一大就会内存溢出。我现在都默认使用search_after方式，用上一页的排序值作为下一页的起始位置，避免了深分页的性能损耗。

第三，对搜索结果只返回必要的字段。默认情况下ES会把整个_source返回给客户端，如果每个文档有2KB大小，返回1万条文档就是20MB的传输量。使用_source过滤或者stored_fields，只返回商品ID、名称、价格、主图URL这几个必要字段，能大幅降低网络传输开销。

第四，批量查询与并发控制。搜索接口拿到商品ID列表之后，通常还需要查询商品详情、库存、评价等信息来组装页面。这一步一定不能用循环逐条调用，要使用批量接口，一次传入几百个ID，同时严格控制并发数量。这个细节做不好，搜索接口的延迟会随着结果数量线性增长。

第五，索引段合并的定时任务。ES的Lucene索引由多个段组成，段越多，查询时需要打开的文件越多，性能越差。建议在业务低峰期，比如凌晨三点，调用_forcemerge接口把段合并到较小数量，能显著提升查询性能。

第六，副本节点的读流量分担。生产环境下，建议至少保留一个副本分片。查询请求会自动负载均衡到主分片和副本分片上，相当于把读QPS翻了一倍。

5.4 写入性能调优与索引生命周期管理

搜索系统不只是要读快，写入也要稳。商品数据的更新频率虽然不高，但大促期间活动商品的数据调整非常频繁。如果写入链路处理不好，索引数据跟不上业务变化，用户搜索出来的商品信息就是旧的。

ES写入的优化有四个方向。一是使用bulk批量写入，一条一条地insert是性能最大的杀手，bulk 批量接口建议每个批次控制在5MB到15MB之间。二是适当调大refresh_interval，默认是1秒，这意味着每条数据写入后最多1秒就可以被搜索到，但频繁刷新会消耗大量IO。如果业务对实时性要求不是特别高，可以调整到30秒，写入性能提升非常明显。三是写入期间临时把副本数设为0，全部写入完成后再恢复副本数，这会触发新的副本复制，但写入性能至少提升50%以上。四是设置合理的translog同步策略，对数据安全性要求不高的场景，可以设置translog异步刷盘来提升写入性能。

索引生命周期管理也要提前做好规划。商品数据是持续增长的，索引大小会随着时间膨胀。我会按照业务约定设置索引的滚动策略，比如按天或按月创建新的索引，配合定时任务把旧索引中已经删除的商品数据清理掉。ES自带的Index Lifecycle Management（ILM）可以自动完成这部分工作，建议提前配置好。

6. 索引数据同步链路：从MySQL到ES的实践方案

6.1 三种同步方案对比：双写、定时任务、Binlog订阅

ES里的数据从哪里来？这个问题很多团队在做架构设计的时候才会认真考虑。商品数据的主库是MySQL，ES只是一个检索副本，如何让副本和主库保持一致就变得至关重要。

目前业内常用的方案有三种。第一种是业务侧双写，就是在更新MySQL的同时，在业务代码里直接掉一把ES的更新接口。优势是逻辑简单，实时性高，但问题也非常突出：业务代码耦合了ES的写入逻辑，一旦ES异常会导致主业务失败，或者MySQL成功而ES失败造成数据不一致。这种方案只适合数据量小、对一致性要求不高的场景。

第二种是定时任务全量或增量同步，每隔一段时间扫描MySQL中的更新时间字段，把变更的数据批量写入ES。优势是实现简单、稳定可控，缺点是实时性差，最快也只能做到分钟级延迟，而且只能同步到更新时间字段明确的数据表，删除操作很难感知。

第三种是Binlog订阅方案，通过Canal监听MySQL的binlog日志，把每次增删改操作转换成消息发布到Kafka，消费端读取消息并写入ES。这是目前大型电商系统最主流的选择，也是我在生产环境用得最多的方案。

这三条链路对比如下：

6.2 Canal监听MySQL与Kafka削峰的完整链路

我用Binlog订阅方案时，采用的完整链路是这样的：MySQL开启binlog日志并把格式设为ROW，Canal伪装成MySQL的从节点去订阅binlog流，解析出每次数据变更的信息后，把变更数据以消息的形式投递到Kafka的某个topic中。每个商品ID按照哈希规则路由到固定分区，保证同一个商品的数据变更消息是有序的。搜索索引构建服务作为Kafka的消费者，从topic里拉取变更消息，解析成ES的增删改请求，批量写入ES。

为什么要在这个环节引入Kafka，而不是让Canal直接对接索引构建服务？因为Kafka的核心价值是做削峰和缓冲。大促期间商品数据变更会有一个明显的峰值，比如运营批量改价、批量上下架，一瞬间会产生大量的binlog变更记录。如果不经过消息队列，这些变更流量直接打到ES，ES的写入性能会被冲垮。经过Kafka之后，消息先堆积在队列里，消费者根据自己的消费能力匀速拉取处理，流量就被消峰填谷了。

我一般会以商品ID作为消息的key值，这样同一个商品的变更操作会进入同一个Kafka分区，保证消息的顺序性。这一点很关键，如果同一条商品的“更新”和“删除”消息被分发到不同分区，消费者处理顺序不一致，最终索引状态可能出错。我用过一个规则：topic的分区数设置成消费者实例数的倍数，这样消费者可以均匀地分摊分区压力。还要设置好消息的保留时间，建议至少保留三天，避免消费者宕机时间过长导致部分消息丢失。

6.3 最终一致性：补偿与对账机制

基于消息的异步同步方案，无法做到强一致，只能保证最终一致。但最终一致也需要有兜底机制来修复异常场景下的数据不一致。

我会在索引构建服务里增加一个补偿任务，每隔半小时扫描一次最近一段时间内发生过变更的商品ID列表，去ES中查询对应商品数据，和MySQL中的数据做一次比对。发现不一致的就重新同步。这个对账任务不能全量扫描，必须按时间窗口增量处理，否则会对数据库造成很大的压力。

还有一些特殊情况需要人工介入。比如MySQL中某条商品数据被物理删除，binlog里可能没有对应的删除记录，或者Canal在推送过程中出现了消息丢失。这时候就需要靠定时比对任务去发现ES中多了而MySQL中已经删除的数据，然后把它们清理掉。

搜索系统的高并发设计实战：从流量入口到索引同步的完整方案

100万并发这个数字，第一次听确实唬人。但做系统设计的第一件事，就是把这个抽象数字翻译成具体的技术动作。这不是一道语文题，而是一道算术题。你需要知道这100万是什么类型的请求、从哪来、到哪去，然后才能谈怎么设计系统。这里说句大实话：没有任何一个单点系统能扛住100万QPS，所谓高并发设计，本质上是把流量拆开、摊平、削峰、填谷，让每一层都只承担自己该承担的那部分压力。商品搜索系统尤其典型，因为它是典型的读多写少场景，用户点一下搜索，后端可能要查缓存、查索引、查商品详情、做排序、做过滤，链路很长，任何一个环节成了瓶颈，整个搜索体验就崩了。

这篇文章我会从整体设计思路、流量入口、缓存层、搜索引擎层、数据同步链路、降级兜底、常见问题几个维度完整拆解，把我这些年做搜索系统踩过的坑和沉淀下来的方案都摊开讲。不管你是准备面试，还是真的要动手搭一套支撑高并发搜索的系统，这篇都能给你一个可以直接照着做的完整蓝图。

1. 先把“100万并发”翻译成系统指标

在画架构图之前，先做一道算术题。假设线上业务确实有100万QPS的请求量，但这里有个常见误区：这100万请求不可能全是搜索请求。用户端的行为分布一般是浏览商品、加购、下单、支付占比更高，搜索请求占整体请求量的20%到30%就算很高了。也就是说，真正打到搜索系统的QPS大概在20万到30万。这个数字依然很大，但已经不是一个让人绝望的量级。

再往下拆，这20万到30万的搜索QPS，也并不是全部都打到搜索引擎。系统设计的一个核心原则就是“每一层都拦截一批流量”。用户发起搜索请求后，第一层是网关和负载均衡，第二层是搜索接口服务，第三层才是搜索引擎（比如Elasticsearch）。搜索接口服务会把结果缓存起来，热门关键词比如“手机”、“连衣裙”、“蓝牙耳机”这种，搜索结果大概率可以直接从缓存返回，根本不需要到搜索引擎走一遍。我做过的一个真实项目里，搜索接口加了Redis缓存之后，实际命中搜索引擎的流量只有总QPS的20%不到。

做系统设计的时候，我习惯先把QPS指标换算成更具体的东西：每台机器能扛多少并发，需要多少台机器，每条查询链路平均延迟要控制在多少毫秒以内，缓存命中率要做到多少以上。这些指标定下来，架构自然就清晰了。我一般按下面这个表格做容量预估：

这套数字从100万一路砍到几万，每砍一层，系统的成本和复杂度都会降一个台阶。这也是为什么我一直强调，高并发系统设计的第一课不是画图，而是先把流量模型算清楚。你连请求长什么样、流量分布如何都不知道，画出来的架构全是纸上谈兵。

2. 商品搜索系统的整体架构设计思路

2.1 核心设计原则：读多写少，缓存为王

商品搜索系统是所有高并发场景里最典型的一种，因为它几乎全是读操作。商品数据的变化频率不高，可能一天只更新几次，但用户的搜索请求是持续不断的。这意味着你完全可以把大量流量拦截在数据库之外，用缓存和搜索引擎构建一条高效的只读链路。

MySQL在这套链路里只承担两个职责：一是商品数据的持久化存储，二是索引重建时提供全量数据源。用户的每一次搜索请求都不应该直接打到MySQL，否则100万并发会立刻把数据库打挂。MySQL的并发上限一般在几千到一万左右，你用它扛几万的查询必然雪崩。正确做法是让它只处理每秒几百次的写入和少量的数据补偿查询，其他所有读流量都交给上层的Redis和Elasticsearch。

2.2 整体链路架构：六层分流模型

我设计商品搜索系统时，内部一直沿用六层分流的思路。这个思路不复杂，核心就是让每一层只干一件事，流量逐层收窄。

第一层是流量入口层，用LVS加Nginx集群做负载均衡和反向代理，负责把请求均匀分发到后端的搜索接口服务，同时承担一些基础的限流、黑白名单拦截。第二层是搜索接口服务层，也就是我们写的业务代码，负责参数校验、搜索词预处理、缓存查询、结果组装和兜底逻辑。第三层是Redis缓存层，负责缓存热门搜索词的结果、搜索热词、商品详情快照。第四层是Elasticsearch搜索引擎层，负责真正的全文检索、分词匹配、多字段过滤、排序打分。第五层是商品详情服务，负责从MySQL或其他存储中读取商品全量信息，这一层在搜索链路里通常是批量调用，不会单条实时查询。第六层是索引构建链路，MySQL的binlog通过Canal和Kafka异步同步到Elasticsearch，保证搜索数据与线上数据最终一致。

这张图里最关键的是第三和第四层的关系。我之前遇到过不少团队，一开始就没设计缓存层，所有搜索词都直接打到ES，结果ES集群规模急剧膨胀，硬件成本翻了好几倍，查询延迟还居高不下。加了缓存之后，同样的流量，ES的写入和查询压力都降低了七八成，整个系统的稳定性和成本都得到了很大的改善。

2.3 为什么选择Elasticsearch而不是MySQL模糊查询

这是搜索系统设计里最常被问的一个问题。商品搜索最核心的是对商品名称、类目、属性做全文检索，还需要支持分词、拼音、同义词扩展、错误纠正、按销量价格排序。MySQL的LIKE查询最大的问题是无法有效利用索引，一旦数据量到了千万级别，全表扫描的耗时直接奔着秒级去。当年MySQL 5.7加入全文索引，效果依然不够理想，对亿级别数据量的搜索场景基本无能为力。

Elasticsearch的底层是基于倒排索引打造的，天生就是为了处理“用关键词找文档”这种场景。它把每个词条映射到包含它的文档列表，查询的时候直接定位词条，然后合并文档列表，速度从分钟级提升到了毫秒级。再加上分片机制可以把数据分散到多台机器上并行查询，水平扩展性非常好。我做的搜索系统里，ES单集群承载了几亿的文档量，查询P99依然可以控制在50毫秒以内，这个量级MySQL几乎不可能做到。

当然，ES也不是银弹。它解决的是检索问题，而不是数据一致性问题。真正要保证商品数据不丢、不重复、顺序一致，还需要一套成熟的数据同步机制，这部分我会在后面的索引构建章节详细展开。

3. 流量入口与网关层：第一道防洪堤

3.1 LVS+Nginx的部署结构与关键参数

流量入口是整个系统的第一道防线，也是流量的命门。100万QPS的请求如果直接打到业务服务上，任何应用服务器都会瞬间被打爆。我的标准做法是使用LVS做四层负载均衡，后面挂Nginx集群做七层反向代理。

LVS工作在内核态，转发能力非常强悍，一台普通的服务器就能支撑几十万甚至上百万的并发连接，而且没有太多可调的东西，基本上就是配置虚拟IP和转发规则。Nginx则承担更细粒度的任务：HTTP协议解析、URL路由、限流控制、静态资源缓存、gzip压缩。Nginx的性能上限一般是一台机器8万到10万QPS，配合多核CPU和高性能调优，可以把这个数值稳定在比较理想的水平。

Nginx有几个关键参数值得留意。worker_processes建议设置为CPU核心数，不要盲目加大，多了反而因为上下文切换开销导致性能下降。worker_connections设置每个worker进程能同时保持的最大连接数，一般按65535配置。keepalive_timeout建议设置在15秒到30秒之间，可以显著降低每个连接的握手开销，提升长连接利用率。还有keepalive_requests，控制单个长连接上最多处理多少个请求，建议设置成1000左右，避免连接被某个客户端长时间占用。

我见过不少团队，Nginx部署完之后不做任何调优，直接用默认配置扛高并发，结果性能直接打了个五折。默认配置往往偏保守，很多参数是按照最低兼容标准设置的，用在高并发生产环境里会明显成为瓶颈。

3.2 限流策略：令牌桶与漏桶的选型

网关层除了分流，还有一个核心任务就是限流。高并发系统的容错设计里，限流永远是排在第一位的手段。当流量超过系统承载能力时，必须有意识地把一部分请求挡在门外，保证大部分用户可以正常使用。

我常用的限流方案有两种。第一种是令牌桶算法，系统的令牌以固定速率生成，请求来了先取令牌，拿到令牌才能继续往下走，拿不到就直接拒绝或者排队。这个算法的优势是允许一定的突发流量，因为桶里预存的令牌可以在瞬间消耗掉一部分。第二种是漏桶算法，请求像一个固定速率的水滴一样从桶里流出，不管上游来多少流量，下游收到的都是匀速的。漏桶的优势是保护下游更彻底，但会牺牲一些突发流量的体验。

商品搜索场景我推荐令牌桶。因为用户的搜索请求天然有波峰波谷，比如大促开始的前几分钟，搜索量会瞬间暴涨到平时的好几倍。如果服务器端用漏桶，整个系统会有大量请求排队等待，用户体验非常差。用令牌桶的话，桶里预存的令牌数量可以设置成平时流量的两到三倍，这样既能平滑掉一部分压力，又能保证突发流量不至于全部被拒。

具体到落地，如果只在一台Nginx上做单机限流，同一个用户可能被不同的Nginx节点处理，限流的边界就模糊了。我的建议是网关层做单机限流，Redis做分布式限流兜底。单机限流处理的是单台机器的保护，分布式限流控制的是整个集群的流量总量。两层配合，既能防单点打挂，又能防整体超载。限流阈值也不是拍脑袋定的，需要按照系统的压测数据进行标定，我会在后面的压测章节详细讲。

4. Redis缓存层：让搜索快如闪电的核心

4.1 缓存什么、缓存多久：缓存策略的确定

商品搜索系统里，Redis的定位是“第一道业务缓存”。它的作用不是让数据存更久，而是让热点数据离用户更近。搜索接口收到一个关键词之后，第一步不是去ES查询，而是先在Redis里查一下这个关键词的搜索结果是否已经被缓存了。如果命中，直接返回，整个过程的耗时通常在10毫秒以内。如果没命中，才去ES查询，然后把结果写入Redis，并设置一个合理的过期时间。

缓存的内容要区分场景。对于搜索结果这种聚合数据，我一般把商品ID列表、总命中数、分页信息序列化存成JSON或者Protobuf，key的设计规则是search:result:{keyword}:{page}:{pageSize}。意思是同一个关键词、同一页、同一页大小的请求会命中同一条缓存。对于热搜词列表，key设计成search:hot:day:{yyyyMMdd}，每天一份，用于支撑搜索框下面的热门推荐。

过期时间也需要谨慎设计。太短了，缓存效果不明显；太长了，用户看到的搜索结果可能和最新的库存、价格脱节。我通常会把基础过期时间设置在5到10分钟，同时加上一个随机偏移量，比如在5到10分钟之间随机浮动，避免同一个时间点大量key同时过期形成缓存雪崩。这个随机偏移量的作用，后面讲雪崩时还会再次提到。

4.2 缓存穿透、击穿、雪崩三板斧

高并发缓存场景绕不开“三座大山”：缓存穿透、缓存击穿、缓存雪崩。这三个问题做搜索系统的时候全部都会遇到，而且每一个都能把系统打挂。

缓存穿透是指查询一个必然不存在的数据，比如用户搜索一个根本不存在的商品词“哈哈哈哈不存在的商品”，缓存里没有，数据库里也没有，每次请求都会穿透到ES和数据库，导致后端压力陡增。解决思路有两个：一是对空结果也做缓存，把不存在的key缓存在Redis里，设置一个较短的过期时间比如60秒，这样重复的穿透请求就被拦截了。二是使用布隆过滤器，把所有可能的商品ID都存进布隆过滤器中，查询之前先判断key是否存在，不存在直接返回，连Redis都不需要查。

缓存击穿是指某个热点key在缓存过期的瞬间，有大量请求同时打到后端。比如某个爆款商品的搜索结果缓存刚好失效，刚好那几秒又有几万个用户搜索这个商品，ES就会瞬间收到几万条重复的查询请求。解决办法是使用互斥锁，缓存过期时只有一个请求能拿到锁去ES查询，其他请求等待锁释放后直接读取缓存。还有一种思路是使用逻辑过期时间，即缓存中存储一个逻辑过期时间戳，请求发现逻辑过期后，先返回旧数据，同时发起异步线程去ES刷新缓存，这种方式对用户体验更友好，代价是实现稍复杂。

缓存雪崩是指大量热点key在同一时间段集体过期，导致后端压力瞬间暴增。解决办法就是我在前面提到的过期时间加随机值，让key的过期时间自然分散开，不形成集中过期的效应。

4.3 热Key问题的四种解法

高并发搜索系统还有一个非常折磨人的问题：热Key。比如“618”、“双11”、“iPhone”这种关键词，一天几十万的搜索量，全部集中在同一个Key上，单台Redis的压力会非常大。Redis是单线程的，热点Key意味着这个Key上的所有操作都在同一个CPU核心上串行执行，其他键值对的访问都会受到影响。

我常用的解法有四种。第一种是本地缓存，在搜索接口服务的JVM里使用Caffeine缓存热点数据，设置一个很短的生命周期，比如5秒，请求到了接口层先查本地缓存，大幅减少对Redis的访问。第二种是Redis集群读写分离，给热Key所在的Redis节点增加从节点，把读请求分散到多个副本上。第三种是Key拆分，把热Key的value拆成多个子Key，比如一个热词的搜索结果拆成10份，请求进来按照某种哈希规则分散到不同的子Key上，压力就摊平了。第四种是给热Key设置较长的TTL，让它尽可能少地进入过期重建的流程。

这四种方案不是互斥的，实际使用中往往需要组合。我的常用组合是“本地缓存+Key拆分”，本地缓存解决单点压力，Key拆分解决单个Redis实例的读写瓶颈。热Key检测也要做成自动化的，通过Redis的monitor命令或者业务埋点监控来识别哪些Key的访问频率异常高，然后自动触发本地缓存策略，而不是纯靠人工每天盯监控。

5. 搜索引擎层：Elasticsearch集群的设计与调优

5.1 集群规模与分片设计

Elasticsearch是搜索系统的真正心脏。它扛下了所有的全文检索、分词匹配、多条件过滤和排序操作。ES集群设计得好不好，直接决定搜索结果的质量和响应速度。

先聊集群规模。假设我们承载的是几亿商品文档，每个文档0.5KB到2KB不等，总数据量大概在几十GB到几百GB之间。这个数据量对ES来说不算大，瓶颈主要在于查询并发。4到6万QPS的查询压力下，我建议至少准备三台数据节点，每台配置32核CPU和128GB内存，同时搭配两台专做协调和主节点的机器。数据节点负责存储和查询计算，主节点负责集群管理、分片分配、元数据维护，职责要分开。

分片的设计是ES调优里的重头戏。分片数量过少，单个分片的数据量过大，查询的并发能力受限。分片数量过多，每个分片都需要一层查询开销，集群管理的负担也会加重。我一般按单个分片不超过30GB到50GB的标准来估算分片总数，再乘以一个冗余系数。比如总数据量300GB，按单分片40GB计算，主分片数量在7到8个左右，加一个副本，那总分片数量就在15个左右。分片数量一旦确定，建索引之后不建议随意修改，因为重新分片意味着全量数据迁移，生产环境代价很大。

5.2 倒排索引的工作原理与Mapping设计

ES的底层是倒排索引。说通俗一点，正排索引是“文档到词”的映射，倒排索引是“词到文档”的映射。给“红色连衣裙”这个词做查询时，ES会先分词，得到“红色”、“连衣裙”这些词项，然后去倒排索引中查找每个词项对应的文档列表，再做集合运算取出包含这些词的文档，最后按相关性打分排序返回。

这个机制带来一个好处：查询速度不随文档数量的增长而线性恶化。因为词项词典本身是排好序的，可以通过跳表、FST（有限状态转换器）高效定位，文档列表的合并也做了大量优化。这也是ES能支撑亿级数据毫秒级响应的核心原因。

Mapping设计对搜索效果的影响非常大。我的经验是，商品名称使用text类型，开启分词器，用于全文检索。商品ID、类目ID、品牌ID使用keyword类型，用于精确过滤。价格、库存这类需要范围查询的字段，使用integer或者long类型。规格参数这类字段多、结构不固定的数据，使用nested类型或者flattened类型，但要慎重，nested查询性能开销较大。对于不需要参与检索的字段，比如商家内部备注、运营备注，直接设置为enabled:false，不建索引，省存储省性能。

5.3 查询性能优化的六个实战要点

ES查询性能优化是搜索系统调优的重头戏。我总结了自己实际项目中验证过的六个有效手段。

第一，尽可能使用filter context而非query context。filter只做过滤不参与相关性打分，ES会对filter的结果做缓存，下次同样的过滤条件会直接走缓存，性能提升明显。价格过滤、库存过滤、类目过滤都应该用filter。

第二，合理使用search_after替代深分页。ES的from+size分页有一个致命问题：深分页时，每个分片都要把前N条数据全部取出来再聚合排序，数据量一大就会内存溢出。我现在都默认使用search_after方式，用上一页的排序值作为下一页的起始位置，避免了深分页的性能损耗。

第三，对搜索结果只返回必要的字段。默认情况下ES会把整个_source返回给客户端，如果每个文档有2KB大小，返回1万条文档就是20MB的传输量。使用_source过滤或者stored_fields，只返回商品ID、名称、价格、主图URL这几个必要字段，能大幅降低网络传输开销。

第四，批量查询与并发控制。搜索接口拿到商品ID列表之后，通常还需要查询商品详情、库存、评价等信息来组装页面。这一步一定不能用循环逐条调用，要使用批量接口，一次传入几百个ID，同时严格控制并发数量。这个细节做不好，搜索接口的延迟会随着结果数量线性增长。

第五，索引段合并的定时任务。ES的Lucene索引由多个段组成，段越多，查询时需要打开的文件越多，性能越差。建议在业务低峰期，比如凌晨三点，调用_forcemerge接口把段合并到较小数量，能显著提升查询性能。

第六，副本节点的读流量分担。生产环境下，建议至少保留一个副本分片。查询请求会自动负载均衡到主分片和副本分片上，相当于把读QPS翻了一倍。

5.4 写入性能调优与索引生命周期管理

搜索系统不只是要读快，写入也要稳。商品数据的更新频率虽然不高，但大促期间活动商品的数据调整非常频繁。如果写入链路处理不好，索引数据跟不上业务变化，用户搜索出来的商品信息就是旧的。

ES写入的优化有四个方向。一是使用bulk批量写入，一条一条地insert是性能最大的杀手，bulk批量接口建议每个批次控制在5MB到15MB之间。二是适当调大refresh_interval，默认是1秒，这意味着每条数据写入后最多1秒就可以被搜索到，但频繁刷新会消耗大量IO。如果业务对实时性要求不是特别高，可以调整到30秒，写入性能提升非常明显。三是写入期间临时把副本数设为0，全部写入完成后再恢复副本数，这会触发新的副本复制，但写入性能至少提升50%以上。四是设置合理的translog同步策略，对数据安全性要求不高的场景，可以设置translog异步刷盘来提升写入性能。

索引生命周期管理也要提前做好规划。商品数据是持续增长的，索引大小会随着时间膨胀。我会按照业务约定设置索引的滚动策略，比如按天或按月创建新的索引，配合定时任务把旧索引中已经删除的商品数据清理掉。ES自带的Index Lifecycle Management（ILM）可以自动完成这部分工作，建议提前配置好。

6. 索引数据同步链路：从MySQL到ES的实践方案

6.1 三种同步方案对比：双写、定时任务、Binlog订阅

ES里的数据从哪里来？这个问题很多团队在做架构设计的时候才会认真考虑。商品数据的主库是MySQL，ES只是一个检索副本，如何让副本和主库保持一致就变得至关重要。

目前业内常用的方案有三种。第一种是业务侧双写，就是在更新MySQL的同时，在业务代码里直接调一把ES的更新接口。优势是逻辑简单，实时性高，但问题也非常突出：业务代码耦合了ES的写入逻辑，一旦ES异常会导致主业务失败，或者MySQL成功而ES失败造成数据不一致。这种方案只适合数据量小、对一致性要求不高的场景。

第二种是定时任务全量或增量同步，每隔一段时间扫描MySQL中的更新时间字段，把变更的数据批量写入ES。优势是实现简单、稳定可控，缺点是实时性差，最快也只能做到分钟级延迟，而且只能同步到更新时间字段明确的数据表，删除操作很难感知。

第三种是Binlog订阅方案，通过Canal监听MySQL的binlog日志，把每次增删改操作转换成消息发布到Kafka，消费端读取消息并写入ES。这是目前大型电商系统最主流的选择，也是我在生产环境用得最多的方案。

这三条链路对比如下：

6.2 Canal监听MySQL与Kafka削峰的完整链路

我用Binlog订阅方案时，采用的完整链路是这样的：MySQL开启binlog日志并把格式设为ROW，Canal伪装成MySQL的从节点去订阅binlog流，解析出每次数据变更的信息后，把变更数据以消息的形式投递到Kafka的某个topic中。每个商品ID按照哈希规则路由到固定分区，保证同一个商品的数据变更消息是有序的。搜索索引构建服务作为Kafka的消费者，从topic里拉取变更消息，解析成ES的增删改请求，批量写入ES。

为什么要在这个环节引入Kafka，而不是让Canal直接对接索引构建服务？因为Kafka的核心价值是做削峰和缓冲。大促期间商品数据变更会有一个明显的峰值，比如运营批量改价、批量上下架，一瞬间会产生大量的binlog变更记录。如果不经过消息队列，这些变更流量直接打到ES，ES的写入性能会被冲垮。经过Kafka之后，消息先堆积在队列里，消费者根据自己的消费能力匀速拉取处理，流量就被消峰填谷了。

我一般会以商品ID作为消息的key值，这样同一个商品的变更操作会进入同一个Kafka分区，保证消息的顺序性。这一点很关键，如果同一条商品的“更新”和“删除”消息被分发到不同分区，消费者处理顺序不一致，最终索引状态可能出错。topic的分区数设置成消费者实例数的倍数，让消费者可以均匀地分摊分区压力。消息的保留时间建议至少设置三天，避免消费者宕机时间过长导致部分消息丢失。

6.3 最终一致性：补偿与对账机制

基于消息的异步同步方案，无法做到强一致，只能保证最终一致。但最终一致也需要有兜底机制来修复异常场景下的数据不一致。

我会在索引构建服务里增加一个补偿任务，每隔半小时扫描一次最近一段时间内发生过变更的商品ID列表，去ES中查询对应商品数据，和MySQL中的数据做一次比对。发现不一致的就重新同步。这个对账任务不能全量扫描，必须按时间窗口增量处理，否则会对数据库造成很大的压力。

还有一些特殊情况需要人工介入。比如MySQL中某条商品数据被物理删除，binlog里可能没有对应的删除记录，或者Canal在推送过程中出现了消息丢失。这时候就需要靠定时比对任务去发现ES中多了而MySQL中已经删除的数据，然后把它们清理掉。

7. 兜底策略：降级、熔断与流量控制

7.1 多级降级方案

再完善的系统也扛不住极端情况。ES集群有可能CPU被打满，Redis有可能内存不够，MySQL有可能连接数耗尽。面对这些异常，系统必须提前设计好降级方案，不能等出了问题再临时拍脑袋。

我做搜索系统时，把降级分成四级。第一级是搜索结果缓存降级，Redis挂了直接跳过缓存层，请求照样打到ES，只是响应慢一些。第二级是ES降级，如果ES的P99延迟明显升高，直接把ES查询熔断掉，从Redis中返回兜底缓存。第三级是热词兜底，当搜索引擎完全不可用时，直接返回运营配置的热门商品列表。第四级是服务降级，返回一个静态的推荐结果页面，保证用户不会看到报错。

每一级降级都需要一个自动触发机制。我用的经验法则是：当接口的错误率超过5%，或者P99延迟超过设定阈值的两倍且持续3分钟，就自动触发降级。这个阈值不是越高越好，也不是越低越好，需要根据业务容忍度来设定。降级之后还要有自动恢复机制，当系统指标恢复正常后，逐步放量切回完整链路。

7.2 熔断与超时设计的细节

高并发系统的稳定性，很大程度上依赖超时和熔断这两个基础能力。搜索接口依赖ES、Redis、商品详情服务，任何一个下游服务变慢，如果没有超时控制，整个服务都会被拖死。

超时设计上，我坚持三个原则。第一是必须设置连接超时和读取超时两个参数，连接超时不能太长，一般300毫秒以内，读取超时根据业务需求设置，搜索场景一般不超过1秒。第二是超时时间要分级，内网服务之间的调用超时设置得比外部服务调用更短，因为内网网络延迟低，超时太长的代价是大量的线程被慢请求占住。第三是超时要配合熔断使用，线程池的拒绝策略里要区分“任务队列满”和“任务执行超时”两种情况，对应不同的熔断动作。

熔断器的原理不复杂。如果连续一段时间内，某个下游服务的错误率超过了阈值，熔断器就会打开，后续请求直接快速失败，不再调用下游服务。过一段时间后，熔断器进入半开状态，放少量请求去探测下游服务是否恢复，如果恢复则关闭熔断器，如果仍然异常则继续保持打开。这个机制避免了“雪崩效应”，让故障的影响范围控制在一个局部里。

7.3 流量控制：如何优雅地拒绝请求

限流解决了“流量超载时怎么处理”的问题，但如何拒绝请求也是一门艺术。直接返回503错误码虽然简单粗暴，但用户体验非常差。我见过很多大厂的做法是：当系统触发限流时，返回一个友好的提示页面，告诉用户“当前搜索人数较多，请稍后再试”，而不是一个冰冷的空白页。

在技术实现上，还有几个值得留意的点。第一，限流返回时一定要带上Retry-After响应头，告诉客户端多久之后再重试，这样可以有效减少客户端无意义的重试请求。第二，要考虑限流的优先级，VIP用户和普通用户的限流阈值要分开，VIP用户允许更高的QPS。第三，限流阈值要在网关层和服务层都配置一份，两层独立工作，任何一层触发都会保护到系统。

8. 常见问题与排查技巧实录

8.1 连接池耗尽问题

搜索系统里最经典的一个故障，就是Redis连接池耗尽。现象是应用日志里大量报错，提示无法从连接池获取连接，频次很高。原因往往是某个请求在获取连接后执行耗时太长的命令，占住了连接不释放，其他请求只能排队等待空闲连接，最终连接池被完全占满。

排查思路分三步。先看Redis的平均命令耗时和慢查询日志，是否出现了类似KEYS或者SMEMBERS这种时间复杂度高的命令，凡是生产环境，这类命令必须禁掉。再看应用所在机器的网络情况，是否因为网络抖动导致命令执行时间变长。最后检查连接池配置，maxTotal设置得是否太小，maxWaitMillis是否设置得足够长。还有一个排查技巧，如果只是个别业务高峰期出现连接池耗尽，优先检查是否有请求在finally块里没有正确归还连接，这是连接池泄漏的典型案例。

8.2 ES集群CPU飙升的原因

ES集群CPU使用率突然飙到90%以上，这是最让人头大的问题之一。我遇到的情况里，最常见的有五种：分页过深、聚合查询过大、前缀查询过重、索引段过多、GC频繁。

处理步骤一般是先查看当前正在执行的查询，使用ES的hot_threads接口或者慢查询日志定位到具体的查询DSL，然后把可疑的查询拿出来单独做分析。深分页问题用search_after替换，聚合查询增加size限制或者改为近似聚合，前缀查询尽量改成edge_ngram分词方式，段过多则做一次forcemerge。如果排查完发现所有查询都正常，可以考虑是不是CPU核数过少或者集群节点数不够，需要做水平扩容。

8.3 缓存命中率上不去的分析

缓存命中率是搜索系统最重要的健康指标之一。如果命中率长期低于50%，说明缓存策略大概率有问题。

常见的低命中原因有几个。一是缓存的key设计太细，比如把筛选条件、排序规则也拼进key里，导致同一个词的不同请求分散到不同的key上，缓存很难命中。解决办法是缩小key的颗粒度，只把核心关键词作为key，筛选和排序在拿到结果之后再做。二是过期时间设置得太短，热词缓存刚写进去就过期了，用户访问还没形成规模就失效。三是没有对无结果词做空缓存，大量不存在的搜索词每次都会穿透到ES。排查缓存命中率问题，最好的办法是给缓存系统增加一个指标埋点，按关键词维度统计访问次数和命中次数，很快就能定位到问题词。

8.4 压测指标上不去的七类原因

每次做容量压测，都会遇到“并发上不去”的情况。根据我的经验，常见原因集中在七类：Nginx没有开启keepalive、后端服务线程池太小、数据库连接池太小、Redis连接池太小、JVM堆内存设置不合理、GC频率过高、日志写入占用太多IO。

压测时我建议分两步走。第一步是单链路压测，只压搜索接口服务，不经过网关，确认服务本身的性能上限。第二步是全链路压测，从Nginx开始到ES结束，跑完整条链路，确认整体瓶颈。每次压测都要记录QPS、响应时间、错误率、GC频率、CPU使用率、内存使用率，对比数据找出瓶颈点。有一个经常被忽视的细节：压测机的并发线程数要按比例放大，不能一直停留在很小的值，否则压测结果会失真。

9. 搜索系统还能怎么玩：两个进阶方向

高并发搜索系统设计到这一步，已经能满足绝大多数业务场景。但如果你追求极致的体验，还有两个方向值得深入探索。

第一个是搜索排序策略的优化。ES默认使用BM25算法做相关性打分，但商品搜索场景里，“相关”不等于“合理”，用户搜索“手机”时，销量百万的旧款手机和刚上架的新款手机，排序逻辑应该完全不同。我在项目中做了多轮调优：在ES打分结果的基础上，引入销量、价格、上架时间、用户个性化偏好等因子进行重排，效果比单纯用ES默认排序好得多。

第二个是人工智能技术在搜索中的应用。比如对用户输入进行意图识别，判断用户是想找品牌、找类目还是找具体商品；对同义词进行扩展，让“笔记本”可以同时匹配到“笔记本电脑”；用向量召回做语义检索，当用户说“适合送女朋友的礼物”时，系统能理解并召回匹配度高的商品。这些方向能极大提升搜索的智能化程度，但实现复杂度也高了一整个量级，适合作为现有系统的进阶演进方向。

聊天记录里看不到你的系统，我看不到你自己的系统，但如果你要问我系统设计的最大心得，那就是一句话：先扛住，再优化，最后才谈智能。没有高并发架构作为底座，一切的搜索策略优化都是空中楼阁。先把流量入口、缓存、索引、同步链路这四件事做扎实，你就有了一副能扛住大促冲击的身体，后面再去做排序优化、智能推荐，都是锦上添花的事情。这套架构从设计到落地，我自己走了不少弯路，希望这份经验能帮你少踩几个坑。