Redis缓存击穿的实现方案中，如何处理复杂数据类型？

JSON存复杂对象不安全，需配置ObjectMapper的WRITE_NULLS和FAIL_ON_UNKNOWN_PROPERTIES；锁粒度应按访问维度生成唯一key并设过期时间；逻辑过期需封装原子写入方法校验expireAt；重建耗时长时应异步执行并设超时与重试。

Redis缓存击穿中，JSON字符串存复杂对象是否安全？

直接序列化成String存进Redis是常见做法，但要注意两点：一是JSON本身不带类型信息，反序列化时若字段类型变更（比如int改成Long），可能抛JsonMappingException；二是空值处理不当会导致null字段被忽略，后续读取时字段缺失。建议统一用ObjectMapper配置WRITE_NULLS和FAIL_ON_UNKNOWN_PROPERTIES开关，避免运行时意外失败。

Map或List结构缓存重建时，锁粒度怎么设？

不要对整个业务模块用一个全局锁（如"cache_lock_all"），否则所有key共用一把锁，变成串行瓶颈。应该按实际访问维度生成锁key，例如查询店铺分类列表时，锁key应为"cache_lock_shop_type_list"；查单个店铺用"cache_lock_shop_123"。锁key必须和缓存key有明确映射关系，且带过期时间（如SETNX cache_lock_shop_123 "1" EX 30），防止持有锁的线程崩溃后锁永远不释放。

逻辑过期方案里，如何避免value中expire字段被误删？

把过期时间塞进JSON value里（如{"data":{...},"expireAt":1752429600000}）看似简单，但容易踩坑：

• 业务代码手动拼接JSON字符串时，expireAt字段可能被遗漏或格式错误；

• 使用StringRedisTemplate存原始字符串，如果中间环节调用opsForValue().set()没带EX参数，Redis物理TTL丢失，仅靠逻辑判断会失效；

• 多线程并发写同一个key时，没加锁就覆盖旧值，导致新写入的expireAt被旧逻辑覆盖。

推荐做法：封装统一的setWithLogicExpire()方法，内部用execute(RedisCallback)保证原子写入，且强制校验expireAt字段存在并为long型。

嵌套对象缓存失效后，重建耗时长怎么办？

比如一个商品详情包含SKU列表、规格参数、评论聚合数据，查库+组装要800ms，这时不能让所有请求都卡在锁等待上。关键点是：锁只保护“触发重建”动作，不阻塞返回。

• 互斥锁方案中，拿到锁的线程立即异步提交重建任务（如用CompletableFuture.runAsync()），然后释放锁，不等结果；

• 逻辑过期方案中，主线程判断expireAt已过期后，直接开新线程重建，自己立刻返回旧数据；

• 两者都需配超时机制：异步任务执行超过3s自动中断，避免拖垮线程池；

• 重建失败要记录日志并重试（最多2次），不能静默丢弃。

真正难的不是写锁或加字段，而是让锁、缓存、数据库三者在异常路径下仍能收敛——比如网络超时、OOM、Redis连接闪断。这些场景下，锁是否自动释放、旧数据是否继续可用、重建任务是否可追溯，才是压测时暴露问题的核心。