CDC

背景 社区对 outbox 表 + CDC 的选型已经讨论得比较透了（见下方引用），我这边已经落地了 outbox + Debezium + Kafka Connect 方案，但踩了一个隐蔽的坑：outbox 表本身的生命周期操作（状态流转

【背景】 我做了 3 年数据工程，最近在一个读多写少、但写路径对一致性敏感的场景里反复纠结一件事：缓存和 DB 到底怎么保证「读到的不是脏数据」。我们这套是 MySQL 8.0 + Redis 7（Cluster，16 shard）+ Sp

背景 团队 8 人维护订单 → 库存 → 支付链路，消费端"至少一次 + 幂等"已做好（幂等表 + 唯一键，TTL 72h），这块不再赘述。今天想聊的是生产端一个更隐蔽的卡点： «本地 DB 事务（insert 订单行 + update 库

背景 社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了