Spring Data Redis Repository findBy偶发返回null 查不到已存在Session记录

已排除的非关联因素 #

• 已确认Redis maxmemory-policy 为noeviction，排除内存不足时key被被动淘汰的场景
• 异常表现为相同查询条件二次执行即可正常返回结果，排除查询条件拼写错误、实体定义不匹配等静态配置问题

核心诱因定位 #

• 老版本Lettuce连接层偶发异常：当前版本组合（Spring Boot 1.5.2 + spring-data-redis 1.5.22）配套使用的Lettuce 4.x客户端存在已知缺陷，长连接空闲超时后，连接池不会主动校验连接有效性，偶发出现命令发送到已重置的失效连接、读取到无效响应的问题。此时基于@Indexed注解的二级索引查询，会因为读取不到正确的索引成员集合返回空结果；下一次查询复用健康连接时，即可正常拿到目标数据，与观察到的异常表现一致。
• 二级索引与实体写入的非原子间隙：Spring Data Redis对@RedisHash标注的实体，写入流程为两个独立的Redis命令：首先将实体序列化写入Hash结构（key为session:实体ID），之后再将实体ID加入对应@Indexed字段的二级索引Set集合。两个操作之间没有事务包裹，若在实体落库完成、但二级索引尚未写入的时间窗口触发查询，就会返回null；待索引写入完成后，同条件查询即可恢复正常。
• 序列化配置不统一导致的字节错位：当前自定义的RedisTemplate仅设置了连接工厂，没有统一配置序列化规则，默认使用原生byte[]读写；但Spring Data Redis的Repository操作，默认对二级索引的key、值使用JDK序列化逻辑。连接重连的瞬间，偶发出现字节流读取偏移，导致索引集合的成员ID解析错误，无法关联到对应实体，最终返回null。
• 布尔类型参数解析的偶发兼容问题：1.5.x版本的Spring Data Redis在解析派生查询方法时，对原始boolean类型字段、包装Boolean类型查询参数的绑定逻辑存在缺陷，偶发出现参数值序列化结果与写入时的索引值不匹配的情况，导致索引匹配失败；后续解析逻辑正常时即可完成匹配。

落地解决方案 #

• 调整Lettuce连接配置：开启连接有效性校验，设置setValidateConnection(true)，为空闲连接添加Keepalive检测，避免失效连接被连接池复用；版本允许的前提下，将Lettuce客户端升级到兼容该Spring Data Redis版本的5.2.x稳定版，修复已知的连接复用bug。
• 统一序列化规则：修改自定义RedisTemplate的序列化配置，与Spring Data Redis Repository的序列化逻辑保持一致，避免字节读取错位；推荐替换为GenericJackson2JsonRedisSerializer作为全局序列化器，同时适配实体存储、二级索引的读写逻辑。
• 补充查询兜底逻辑：针对findByInternalChatIdAndActive这类依赖二级索引的查询，若首次查询返回null，可通过已知业务主键直接查询实体Hash结构做兜底，规避索引写入间隙、连接异常导致的偶发空结果。
• 规避写入间隙风险：实体写入完成后，主动追加一次索引的写入确认，缩小非原子操作带来的时间窗口影响。

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