Cache-Aside（旁路缓存）是最常用模式：读操作先查Redis，命中则返回，未命中则查数据库并回写带TTL的缓存；写操作推荐先更新数据库再删除缓存，避免并发不一致。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您正在使用 CodeGeeX 辅助开发，需为其生成高效、可落地的 Redis 缓存读写逻辑，则核心在于准确建模缓存行为、规避常见陷阱，并适配真实应用的数据流。以下是实现高性能数据缓存与读取逻辑的多种技术路径：
一、前置缓存模式（Look-aside Cache）
该模式由应用层主动控制缓存生命周期，读请求先查 Redis，未命中再查数据库并回填缓存，适用于绝大多数 Web 服务场景，具备强可控性与低耦合性。
1、在应用初始化阶段建立连接池，复用 Redis 客户端实例，避免频繁创建连接开销。
2、定义缓存键命名规范，例如 user:profile:{uid} 或 article:hot:{category}:page:{n}，确保语义清晰且支持批量操作。
3、执行读取逻辑时，调用 GET 命令获取缓存值；若返回 null，则触发数据库查询，并在获取结果后立即执行 SETEX key seconds value 写入带过期时间的缓存。
4、对高频但低变更率的数据（如用户基础资料），设置较长 TTL（如 3600 秒）；对时效敏感数据（如价格、库存），TTL 应缩短至数秒或采用逻辑过期方案。
二、写穿透模式（Write-through Cache）
该模式要求所有写操作必须同步更新数据库与缓存，保障强一致性，适用于金融、订单等对数据准确性要求极高的业务链路。
1、封装统一写入函数，内部按顺序执行：先写数据库事务提交成功，再执行 SET 或 HSET 更新 Redis 中对应键值。
2、为防止缓存写入失败导致脏数据，添加重试机制与错误日志，例如对 cache.setex() 失败时记录告警并触发异步补偿任务。
3、对哈希结构缓存（如用户信息），使用 HSET user:{uid} name "Alice" age 28 替代序列化整个对象，降低网络传输与解析成本。
4、配合 Lua 脚本实现原子性写入，例如在更新计数器的同时刷新最后更新时间戳：EVAL "redis.call('HINCRBY', KEYS[1], 'views', 1); redis.call('HSET', KEYS[1], 'updated_at', ARGV[1]);" 1 user:1001 1713424890。
三、防穿透+防击穿组合策略
针对恶意构造不存在 Key 或突发热点 Key 导致 DB 压力激增的问题，需在缓存层前置布隆过滤器与互斥锁机制，从源头拦截无效请求。
1、在接入层初始化布隆过滤器（如 RedisBloom 的 BF.CREATE），对所有合法用户 ID、商品 SKU 等主键进行预加载。
2、读取前先执行 BF.EXISTS filter_key item_id，若返回 0，则直接返回空响应，不查 Redis 也不查 DB。
3、对可能存在的热点 Key（如首页 Banner 配置），在缓存失效瞬间使用 SET key value NX EX 30 尝试设置互斥锁，仅首个请求穿透 DB，其余等待锁释放后重试读缓存。
4、为避免锁长期占用，互斥锁 TTL 必须显著短于业务缓存 TTL，例如缓存设为 3600 秒，锁设为 30 秒 并配合超时自动释放。
四、多级缓存协同架构
将本地内存缓存（如 Caffeine）与 Redis 组合成两级结构，既降低远程调用延迟，又保障节点间数据最终一致，适合高并发读场景。
1、首次访问某 Key 时，先查本地缓存，未命中则查 Redis；Redis 未命中再查 DB，并依次写入 Redis 与本地缓存。
2、本地缓存设置较短 TTL（如 60 秒）和最大容量（如 10000 条），启用 LRU 或 LFU 淘汰策略，防止内存溢出。
3、当 DB 数据变更时，通过消息队列（如 Kafka）广播 invalidate:user:1001 事件，各服务节点监听后主动清除本地对应条目。
4、Redis 层仍保留完整数据副本与长 TTL，作为本地缓存失效后的兜底来源，确保系统整体可用性不受单节点影响。
五、基于 Redis Streams 的变更通知驱动缓存更新
利用 Redis Stream 作为轻量级事件总线，在数据源变更时主动推送更新指令，替代轮询或定时刷新，提升实时性与资源利用率。
1、数据库写入成功后，向 Stream 写入结构化事件：XADD stream:updates * op "UPDATE" table "users" id "1001" ts "1713424890"。
2、独立消费者组订阅该 Stream，解析事件内容，执行对应缓存更新动作（如 HSET user:1001 ...）或删除动作（如 DEL user:1001）。
3、消费者实现幂等处理，依据事件 ID 或业务唯一键去重，避免重复更新引发数据错乱。
4、配置消费者组自动确认机制（XACK），并监控 XINFO GROUPS 中的 pending 数量，及时发现积压异常。
