Rails缓存未失效排查：基于Memcached的搜索缓存异常

你的缓存逻辑核心思路没问题，但忽略了关键的筛选参数where_clause，这就是点击X/Y/Z按钮后产品数量没变化的原因：

核心问题 #

你提到的X/Y/Z按钮对应不同的筛选条件，这些条件应该是通过where_clause传递给Elasticsearch的，但你的缓存键生成代码cache_string里，只拼接了q、fields、per_page、page、sort_clause，完全没包含where_clause。这就导致：只要其他参数不变，哪怕切换不同的筛选条件（where_clause变化），缓存键依然相同，程序会直接返回旧缓存结果，自然看不到产品数量的变化。

修复步骤 #

1. 将where_clause加入缓存键生成逻辑
   修改cache_string的生成代码，把where_clause也纳入，确保不同筛选条件能生成唯一缓存键：

   cache_string = q.to_query('q') + fields.to_query('fields') + per_page.to_s + page.to_s + sort_clause.to_query('sort') + where_clause.to_query('where')
   

2. 优化缓存键生成方式（可选）
   直接拼接字符串可能存在参数边界歧义（比如参数值包含特殊字符时），建议用哈希统一管理参数后再序列化，更稳妥：

   cache_params = {
     q: q,
     fields: fields,
     per_page: max_per_page(per_page) || 30, # 用处理后的分页值，避免原始值和实际查询值不一致
     page: page || 1,
     sort: sort_clause,
     where: where_clause
   }
   cache_string = cache_params.to_query
   

   这里注意要使用实际传入Elasticsearch的参数值（比如处理后的max_per_page(per_page)，而非原始的per_page），避免出现参数逻辑不一致导致的缓存错误。

3. 验证缓存键唯一性
   可以在代码中临时输出cache_value，确认切换X/Y/Z按钮时，缓存键是否会对应变化——如果变化了，说明缓存逻辑已经正确区分不同筛选条件。

补充说明 #

你对缓存的核心理解是正确的：通过查询参数生成唯一缓存键，相同参数复用缓存结果。只是漏了关键的筛选参数，导致缓存键无法区分不同的查询场景。

内容的提问来源于stack exchange，提问作者knirirr