从「拉」到「推」：CDC 的范式转变

Postgres 原生的逻辑解码（logical decoding）只负责把 WAL 日志翻译成行级变更流，剩下的重担全部甩给客户端：回填、Schema 变更处理、表创建与删除、快照对齐、故障重启……这些步骤中的任何一个出问题，整条管道就会断裂。

Snowflake 的方案名为 Data Mirroring（数据镜像），核心理念极其简单：不再让外部系统来「拉」数据，而是从 Postgres 内部主动「推」。具体实现是一个名为 snowflake_cdc 的 Postgres 扩展，它在后台持续将变更批量写入每张表的变更日志（change log）和一个元日志（meta log），底层存储格式为 Apache Iceberg（压缩 Parquet 文件）。

为什么选对象存储？因为 Amazon S3 这类服务本身具有高可扩展性和高可靠性，Postgres 备份早已在使用。作为 CDC 数据的目的地，它比任何自定义中间件都更稳。

四阶段时间线解耦

Data Mirroring 将一次写入拆解为四个连续但解耦的阶段：

1. 写入（Write）：数据修改表并产生 WAL 记录

2. 解码（Decode）：历史 WAL 被翻译成行级变更，利用 Postgres 的「历史快照」功能读取写入时刻的目录表状态

3. 捕获（Capture）：行级变更被分批收集，定期追加到 Iceberg 变更日志

4. 应用（Apply）：Snowflake 端以有限状态机方式执行元日志指令，将变更批次合并到目标表

这种设计的精妙之处在于：即使某张表在解码时已被修改甚至删除，历史快照仍能保证 WAL 记录被正确理解。Schema 变更走的是同一条 Write→Decode→Capture 路径，自然地嵌入变更流中，不会出现时序错乱。

交易边界：用分布式系统的最简原语解决最难的问题

数据库系统用一个简单原语隐藏了海量复杂性：事务（transaction）。事务失败就重试，成功就保证恰好执行一次——这正是 ETL/CDC 最缺乏的保证。

Snowflake 此前发布的 pg_lake（已正式可用）让 Postgres 能够跨 Postgres 表和 Iceberg 表执行事务。Data Mirroring 在此基础上更进一步：Postgres 端在一个事务内把数据和 Schema 变更批量推入多个 Iceberg 变更日志，Snowflake 端在一个事务内合并多个批次。这意味着所有 Snowflake 表精确推进到某个 Postgres 事务边界，外键和联接的正确性得到保证。

不做 Upsert：插入密集型场景的性能飞跃

传统复制方案普遍采用 upsert（插入或更新）策略，原因是很难解决快照与变更的一致性问题。但 upsert 在列式存储上有严重缺陷：每次插入都要匹配目标表已有行，代价极高；且无法高效地将近期变更与已有数据合并。

由于 Data Mirroring 是受控的事务性过程，它可以生成完美的删除流和插入流，精确执行一次，不存在重复应用的风险。结果是：插入密集型工作负载（通常是最大的表）的复制速度极快且成本低廉，因为插入只是追加，永远不做 upsert。

Live Views：低频应用也能获得低延迟

基于上述能力，Snowflake 推出了 Live Views（实时视图）功能：将未应用的变更日志与目标表数据结合，查询时直接将过滤条件下推到存储层，同时扫描 Parquet 变更日志和基表。即使变更应用频率不高，Live Views 的延迟仍能控制在 1 分钟以内，且查询性能几乎不受影响。

Slot 总结道：「你设置一次，它永远运行。」没有外部连接器会落后，没有快照冲突，没有随表增长而减速的 upsert——只有一个 Postgres 扩展往对象存储推批次，一个 Snowflake 端事务性地应用它们，两边独立运行，永不停歇。

来源：Snowflake 工程博客 / Marco Slot

旧方案的问题出在「两套账」。库存计数存在 Redis 里（占用就减、释放就加），但真正的库存总账在 MySQL。两步没法打包成一个原子操作，一旦顺序出错，就会出现超卖（东西卖了却没从总账扣掉）或幽灵库存（扣了却还显示占用）。Redis 也不感知多仓库库存，还得单独养一个集群。

新方案靠的是 MySQL 8 的 SKIP LOCKED 特性。核心思路是「每个可售单元存一行」，而不是「每个商品存一行数量」。一件有 10 件库存的商品就对应 10 行，预留 3 件就是一次性锁 3 行、挪进预留表。为避免行数爆炸，每个商品/仓库最多维持 1000 行可用池，不够了再由补充进程从总账补齐。SKIP LOCKED 让并发请求跳过被锁的行、直接拿别的可用行，不用排队。

几个工程细节值得记：把主键改成复合主键（店铺、商品、分组、序号），每行锁从两把降到一把；把事务隔离级别从默认的「可重复读」降到「读已提交」，避开空表补充时的间隙锁死锁；统一「先删后插」的锁顺序，消除预留与扣减路径间的循环等待；再用 UNION ALL 把一单多件的查询合并成一次往返。

最有意思的是真瓶颈不在数据库。调完表结构，吞吐量还是卡在目标线下，CPU 也没跑满。团队给每条 SQL 打上业务标签（例如「conn_tag:checkout_completion」），在数据库代理层按调用方统计连接占用时长，才发现是结账链路上的其他环节长时间霸占连接。清理掉这些长事务后，主库读操作减少 50%、事务数减少 33%。

迁移采用影子模式：Redis 和 MySQL 双写一段时间，确认无误再逐步把「真相源」切到 MySQL，并保留一键回滚。

说白了，很多「必须上 Redis」的判断，只是因为当年 MySQL 还没有 SKIP LOCKED 这类能力；如今你手上的数据库往往就够用。真正的瓶颈常常藏在代码里的连接管理，而不是引擎本身。下次想引入新中间件之前，不妨先看看现有数据库的新特性和连接画像。

来源：Shopify 工程博客（作者 Emilie Noel，2026-05-12）