Redis 缓存与查询优化

面试回答

主要是减少几类重复开销。机型资料和部分统计结果会被反复查询，直接回源会重复执行 SQL 和聚合；知识检索中，同一个问题反复生成查询向量也会增加模型调用；多轮问答还需要频繁加载近期消息。

因此我用 Redis 缓存业务读结果、查询向量以及近期对话和常用偏好，让重复请求尽量复用已有结果。MySQL 仍保存业务记录、消息和来源，Redis 中的数据可以回源重建。真正调度、审批或者修改资源时，仍然查询当前业务事实并校验，避免把缓存中的旧状态直接当作执行依据。

面试回答

我把缓存分为三类。业务读缓存保存机型资料、部分查询和经营统计，减少重复 SQL；查询向量缓存保存问题的 embedding，避免重复编码；近期对话缓存保存组织、用户和会话范围内的近期消息，加快上下文装配。

缓存内容需要能够从持久化记录或模型计算重建。资产现在能否调度、任务有没有冲突、工单是否允许提交，这些在实际执行前仍然按当前事实检查。查询向量命中也只省掉编码步骤，后续知识检索依然要带当前权限、时间和版本条件，不能把向量缓存当成可直接复用的答案。

面试回答

读取时先查 Redis，命中就使用缓存结果，未命中则查 MySQL，再回填并设置 TTL。修改时先提交数据库事务，再删除受影响的缓存，由下一次读取重建。

选择删除而不逐一更新，是因为一次业务修改可能同时影响详情、列表和多个统计结果，全部重新计算容易复杂且遗漏。比如成本单据审核后，要让相关展示和统计失效。删除放在事务提交后，避免其他请求在新事务尚未提交时就查到旧值并重新缓存。并发回填和删除失败仍需单独处理，这个顺序本身不能保证强一致。

面试回答

Key 要包含所有会影响结果的范围和查询参数。业务详情通常包含组织、资源类型和资源 ID；统计还要加有效数据范围、时间区间和条件；对话按组织、用户和会话隔离；查询向量则按模型版本、编码配置和查询文本区分。

同一个组织里，不同成员能看到的记录可能不同，所以只加组织 ID 还不够，涉及数据范围的结果要继续区分。命中缓存也不能跳过必要的访问校验。查询向量只是文本编码，可以在编码兼容时复用，但真正检索时仍然应用当前用户的知识库、权限、时间和版本条件。

面试回答

查询向量必须和文档索引处在兼容的向量空间。模型版本、维度或预处理方式变化后，即使查询文本一样，生成的向量也可能不兼容，所以 Key 中要包含模型和编码配置，升级时使用新的缓存命名空间。

文本规范化只处理无意义差异，比如首尾空白，不能把地区、日期、机型编号删掉，否则不同问题可能共用同一个向量。缓存的是问题编码，文档内容更新后，如果编码配置没变，查询向量仍可使用，再对当前索引执行检索；旧模型向量则不能直接与新索引混用。

面试回答

TTL 根据数据变化频率、回源成本和能接受的陈旧时间分别设置。相对稳定的机型资料可以长一些，频繁变化的业务查询和统计短一些，并配合写入后的主动失效。查询向量在模型不变时比较稳定，过期主要用于控制容量和淘汰旧问题。

近期对话同时限制会话过期时间和消息数量，避免无限增长。大量同类缓存再给基础 TTL 增加少量随机偏移，减少同时失效造成的回源高峰。TTL 只是限制旧值可能保留的时间，在有效期内也可能已经过时，所以执行操作前仍然检查当前业务事实。

面试回答

我们采用先提交数据库修改、再删除相关缓存，下一次读取回源重建。对普通展示数据，接受短时间最终一致，通过主动失效和 TTL 限制陈旧窗口；删除失败会记录并补偿，不能只打日志就结束。

这个方案仍然存在并发窗口，比如请求 A 查到旧值，请求 B 更新数据库并删除缓存，之后 A 才把旧值回填。TTL 能限制它存在多久，但不能消除这个窗口。因此调度、审批和权限判断在执行时重新查询当前事实，不直接根据展示缓存决定是否写入。我会把展示一致性的要求和业务执行的正确性分别处理。

面试回答

Redis 不可用时按缓存类型回源。业务读结果回 MySQL，查询向量重新调用编码服务，近期消息从 MySQL 按需要加载。同时限制超时和并发，避免缓存故障把所有压力直接转移到数据库或模型服务。

热点 Key 失效时，会合并同一个 Key 的重建请求，让一个请求加载，其他请求等待或受控回源，减少相同 SQL 和编码任务同时执行。这只是缓存重建保护，不能替代业务事务或状态锁。监控时也区分正常未命中和缓存服务故障，分别看命中率、回源耗时和错误数量。

面试回答

我会固定数据规模、请求分布和并发条件，对比启用缓存前后的完整请求。业务查询看缓存命中率、数据库查询次数，以及平均耗时和 P95；查询向量缓存再看实际 embedding 调用次数；同时检查数据更新后多久能在查询结果中看到。

实验还要区分未预热和已预热，避免把一次理想命中当成全部请求表现。只有重复 SQL 或编码次数下降、用户等待改善，并且结果陈旧时间在可接受范围内，才能说明缓存起到了作用。单看 Redis 读取很快，无法证明整个业务接口变快，更不能说明数据更新仍然正确。