先写MongoDB再写Redis在Node.js微服务中极易导致数据不一致，应改用变更流监听+幂等写入的异步解耦方案。
先写MongoDB还是先写Redis？别选这个顺序
在Node.js微服务里硬套“先写DB后写Redis”的逻辑，基本等于主动埋雷。MongoDB不是传统关系型数据库，它默认不开启事务跨集合操作，更不支持与Redis共用一个分布式事务上下文。你写的 await mongoCollection.updateOne(...) 成功了，await redisClient.set(...) 却因网络抖动失败，此时没有回滚机制，MongoDB里是新数据，Redis里还是旧值或空——而你的读请求大概率走的是Redis，用户看到的就是错的。
为什么不能用“延迟双删”对付MongoDB+Redis
延迟双删（先删Redis → 写MongoDB → 睡眠几百毫秒 → 再删Redis）是为MySQL+Redis设计的，它依赖MySQL主从同步延迟可预估、且缓存层只做读加速。但MongoDB常被用作文档主存（比如订单快照、用户行为日志），本身承担着最终数据源角色；同时它的副本集同步延迟波动大，sleep固定毫秒数既无法覆盖慢同步场景，又会拖慢写链路。更关键的是：如果Redis里压根没这条数据（比如首次写入），两次DEL毫无意义，反而增加Redis负载。
真正能落地的方案：Binlog式监听 + 幂等写入
Node.js里最可控的做法，是让MongoDB自己“发声”，而不是业务代码双写。MongoDB 4.0+ 支持变更流（Change Streams），它比伪Binlog更轻量，且天然支持集群部署：
- 启动一个独立服务（如
mongo-change-watcher），监听目标集合的update、replace、delete事件 - 变更事件中提取
_id和关键字段，生成幂等键（例如user:profile:${_id}:v${timestamp}） - 写入Redis前先检查该键是否存在且版本更低，避免旧事件覆盖新数据
- 失败时把事件写入本地
retry_queue集合，用定时任务重试，而非抛异常中断主流程
这样业务层只需专注写MongoDB，Redis更新完全异步解耦，也不用在每个微服务里重复实现补偿逻辑。
容易被忽略的坑：MongoDB _id 类型和Redis key 设计
Node.js驱动默认把MongoDB的 ObjectId 转成字符串，但如果你在Redis里用它当key，要注意两点：
-
ObjectId字符串长度固定24位，但部分老版本驱动可能补零或截断，建议统一用doc._id.toString()标准化 - 不要直接拼接
"cache:" + doc._id当key——一旦MongoDB里改了_id生成规则（比如切到UUID），Redis里所有key就失效；应加一层命名空间映射，例如用cache:user:profile:${hash(doc._id)} - Redis写入必须带过期时间（
EX），否则MongoDB删掉文档后，Redis里残留key会导致后续读取返回空对象而非null，业务判断逻辑容易出错
一致性不是靠一次写对，而是靠每次写都留好退路。变更流监听可以挂，但只要MongoDB副本集还在工作，重放历史oplog就能追平；幂等键和TTL能防止脏数据长期驻留。这才是微服务里真正扛得住压测和故障的双写逻辑。
