不能靠Kafka单独解决缓存击穿写回竞争，因其不保证同一key仅被一个消费者处理，也无跨消费者互斥机制；必须结合Redis原子锁（如SETNX或Lua脚本）实现并发控制，Kafka仅作异步通知。
直接结论：不能靠 Kafka 单独解决缓存击穿时的写回竞争，必须用 Redis 的原子操作（如 SETNX 或 Lua 脚本）先抢锁，再发消息触发异步重建；否则多个消费者会同时查库、重复写缓存，甚至写入脏数据。
为什么不能让 Kafka 消费者直接重建缓存？
Kafka 本身不保证“同一 key 只被一个消费者处理”，也不提供跨消费者互斥能力。哪怕你把 refresh_user_123 发到单分区 topic，只要 consumer group 有多个实例，就可能被不同 consumer 同时拉取——尤其在 rebalance 或消息重试时。
典型错误现象：
- 日志里看到 3 个 consumer 几乎同时执行
SELECT * FROM user WHERE id = 123 - Redis 中
user:123被反复覆盖，version 字段来回跳变 - 前端轮询拿到的结果忽新忽旧，状态不一致
正确做法：Redis 锁 + Kafka 异步通知组合
核心逻辑是“只让第一个穿透请求发消息，其余全部等结果”，把并发控制压在 Redis 层，Kafka 只做轻量通知。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键步骤：
- 请求到达时，先用
SET user:123:lock "1" NX EX 30尝试加锁；失败则轮询GET user:123直到非空或超时 - 加锁成功者，立即发一条
refresh_user_123到 Kafka，并设置user:123:pending标记（防止重复发） - Kafka 消费者收到后，查 DB 构建全量数据，用
SET user:123 "{json}" EX 3600写入（不带 NX），再DEL user:123:lock - 所有等待线程在锁释放后读到新缓存，无需再触发重建
容易被忽略的三个实操细节
很多项目按上述流程写了，仍出现击穿，问题往往卡在这几个地方：
-
SETNX的过期时间必须显著长于 DB 查询 P99 耗时（比如查库 P99 是 800ms，锁至少设 5s），否则锁提前释放，第二个线程又进来了 - 消息体里必须带时间戳或 version，消费者写缓存前要先
GET user:123:version对比，旧版本直接丢弃——避免因消息乱序导致缓存倒退 - Kafka 消费者必须开启
enable.auto.commit=false，并在SET成功后再手动commitSync()，否则写缓存失败但 offset 已提交，这条消息就永久丢失了
真正难的不是发消息，而是让“锁的生命周期”“消息投递语义”“缓存写入原子性”三者严丝合缝对齐。少一环，防护就漏风。
