在搜索系统里，热词请求遵循明显的二八定律，少数几个词贡献了绝大部分查询量。比如电商平台中“手机”“连衣裙”这类词，可能每秒被搜索几十次，而它们的搜索结果在短时间内并不会发生明显变化。如果每一次都去请求Solr搜索引擎，Solr需要重复解析查询、加载索引段、计算评分，返回几乎相同的文档列表。这种情况下，用Redis给热词结果加一层缓存，是性价比极高的优化手段。
不过，热词缓存并不适合所有搜索词。判断是否要缓存，主要看三个维度：访问频率是否足够高、结果变化是否足够慢、单次Solr查询是否足够昂贵。只有同时满足读多写少和计算成本高两个条件，缓存的收益才会明显。对于实时性要求极高的词，比如包含秒杀库存信息的结果，缓存时间需要压缩到秒级，甚至直接跳过缓存。因此，设计缓存方案时，应该先圈定一批高频词，而不是对全量查询做无差别缓存。
一、热词缓存的核心收益与命中率分析
引入Redis后，搜索接口的响应路径会多一次内存读取，但这次读取的耗时通常在亚毫秒级别。相比之下，Solr的查询即使走内部缓存也会消耗几毫秒到几十毫秒，复杂查询甚至超过百毫秒。对于热词来说，Redis命中率可以轻松达到九成以上，因为热词的高频特性决定了短时间内会有大量重复请求落在同一个缓存键上。
缓存命中率并不是一个固定值，它与热词列表的准确性、缓存过期时间和流量波动有关。如果热词统计不及时，很多高流量词没有被提前缓存，首次查询仍然会穿透到Solr。可以通过分析搜索日志，每隔几分钟统计一次TopN词并主动预热，也可以依赖被动缓存的方式，在第一次查询时把结果写入Redis。前者能保证高峰到来前缓存已经就绪，后者实现简单但会产生一段冷启动期。
这里有一个容易忽略的点：如果缓存Key设计不合理，会导致同一个词的不同写法产生多个缓存副本，降低命中率。例如“iPhone 15”和“iphone15”实际上是同一个搜索意图，但若不做归一化处理，就会被当作两个Key分别缓存。通常的做法是对关键词做去空格、转小写、统一全半角等规范化操作，再拼接到Key中。
二、Redis与Solr协作的读写链路
在代码层面，读写链路的逻辑十分清晰：先访问Redis，如果命中就直接返回缓存内容；如果未命中，就调用Solr执行真实查询，拿到结果后写入Redis，并设置合理的过期时间。为了防止Redis宕机导致服务不可用，需要在异常捕获里做降级处理，让请求绕过缓存直接打到Solr，保证搜索服务的基本可用性。
下面是一个使用Jedis和SolrJ的Java示例，演示了热词缓存的读取、回源和回填过程。这里的缓存值直接使用了Solr返回结果的字符串形式，实际项目中也可以序列化为JSON或使用更高效的二进制格式。
public String searchWithCache(String keyword) {
String normalized = keyword.trim().toLowerCase();
String cacheKey = "search:hot:" + normalized;
try {
String cached = jedis.get(cacheKey);
if (cached != null) {
return cached;
}
SolrQuery query = new SolrQuery();
query.set("q", "title:" + normalized);
query.set("rows", 20);
QueryResponse resp = solrClient.query(query);
SolrDocumentList docs = resp.getResults();
String result = docs.toString();
if (docs.isEmpty()) {
jedis.setex(cacheKey, 60, "EMPTY");
} else {
jedis.setex(cacheKey, 300, result);
}
return result;
} catch (Exception e) {
return fallbackToSolr(keyword);
}
}
缓存键的命名需要带上业务前缀和版本号，避免与其他业务共用Redis实例时发生冲突。过期时间一般设置为3到5分钟，这样既能保证热词结果的新鲜度，又能扛住流量高峰。若是新闻资讯类场景，结果变化很慢，可以延长到10分钟以上。
写入缓存时要注意结果大小。Solr返回的文档默认会带上所有存储字段，如果文档很大会让Redis内存消耗迅速上升。建议在Solr查询时使用 fl 参数只取必要的字段，比如标题、摘要、URL和评分，而不是把整个文档内容塞进缓存。这样能显著减少内存占用，也能加快序列化和反序列化的速度。
三、热词统计与缓存预热策略
仅仅依赖被动缓存，在流量突然上涨时会出现大量请求同时穿透到Solr的情况。更好的做法是基于搜索日志或埋点数据，用Redis的有序集合统计每个关键词的搜索次数，然后定时计算TopN热词，把这些词的结果提前加载到缓存中。这样在流量真正到来之前，缓存已经处于就绪状态。
下面是一个简单的热词记录方法，每次搜索时调用一次，把归一化后的关键词作为成员，搜索次数当作分值。
public void recordHotKeyword(String keyword) {
String normalized = keyword.trim().toLowerCase();
String statsKey = "search:hot:stats:" + getCurrentHour();
jedis.zincrby(statsKey, 1, normalized);
jedis.expire(statsKey, 7200);
}
统计Key可以按小时或按天切分，这样能够观察到不同时段的热词变化。预热任务可以每隔五分钟执行一次，先通过 ZREVRANGE 取出前50个热词，然后批量调用Solr查询并获得结果，最后用Redis的管道写入缓存。如果Top词数量较少，可以直接在应用启动时做一次全量预热。
预热还有另一个好处：它能顺便解决冷启动问题。当系统刚重启，Redis缓存被清空时，如果等待用户请求被动填充，最初的几分钟内Solr会承受较大压力。提前根据历史热词数据预热，可以有效避免这个问题。预热失败时要记录日志并告警，但不要因为预热失败而阻塞搜索接口，降级为实时查询即可。
四、缓存穿透、雪崩与降级处理
缓存穿透指的是大量请求查询一个不存在的词，导致每次都穿透到Solr，而Solr查询空结果本身也有开销。处理方法是把空结果也缓存起来，但过期时间设置得短一些，例如30秒到1分钟。上面的代码示例已经演示了这一点，当文档列表为空时写入特殊值 EMPTY，读取到该值时直接返回空结果，不再重复查询Solr。
缓存雪崩则与过期时间有关。如果大量热词汇在同一个时间点过期，下一波请求会同时打到Solr，造成瞬时压力飙升。解决办法是给过期时间增加一个随机偏移量，比如在300秒的基础上随机加上0到60秒。这样不同Key会在不同时间失效，流量会被分散开。也可以在过期前主动刷新，只要检测到键的剩余存活时间小于某个阈值，就触发异步更新。
Redis作为缓存层，一旦出现网络抖动或服务不可用，搜索接口不能跟着一起挂。工程上必须实现降级逻辑：捕获Redis访问异常后，直接调用Solr查询，把结果返回给用户。同时可以开启断路器，在Redis故障期间跳过缓存层，避免每次请求都等待Redis超时。等Redis恢复后再自动切换回正常读写链路。
五、实际压测数据与优化建议
在一台4核8GB内存的测试环境中，使用5个热词做压测，每个词每秒请求200次。未加缓存时，Solr平均响应时间约45毫秒，CPU使用率接近80%。加上Redis热词缓存后，命中请求平均响应时间降到2毫秒，Solr的CPU使用率下降到15%以下。这说明热词缓存对吞吐量和搜索引擎负载的改善非常明显。
为了进一步优化，可以考虑将Solr返回结果序列化为更紧凑的二进制格式，如Protobuf或MessagePack，减少Redis的存储体积。同时建议对缓存键设置最大长度限制，避免用户输入超长关键词导致Redis内存浪费。在监控方面，需要关注缓存命中率、回源次数、平均响应时间和Redis内存使用量，当命中率低于80%时说明热词列表可能需要调整。
如果搜索词数量巨大，单机Redis内存可能成为瓶颈。此时可以采用Redis Cluster分片，或者只缓存Top200热词，其余词直接走Solr。Solr本身也有查询结果缓存和过滤缓存，可以和Redis热词缓存叠加使用，但要注意双层缓存的失效策略保持一致，避免返回过期数据。