Agent改完数据忘了排活？谷歌把队列塞进数据库

Agent 把订单状态从"待支付"改成"已支付"，然后没有然后了。该发的确认邮件没发出去，而数据看起来完全正常。

10 月 2 日，谷歌宣布 Spanner Queues 正式全面开放。它要做的事一句话能说完：让"改数据"和"排下一个任务"变成同一次提交，要么一起成，要么一起不成。

队列从外部中间件变成表里的一行

过去的做法是把两件事分给两个系统：业务数据写进数据库，待办任务发进消息队列。数据提交成功、消息没发出去，任务就永久丢了；消息发出去了、数据回滚了，任务又会对着一个不存在的状态往下跑。这个窗口很窄，但它一直在。

Spanner Queues 只是换了个位置：消息不发给外部服务，而是写进 Spanner 的表，成为一行普通的行。它和触发它的那次数据变更在同一个读写事务里提交，谷歌把这种操作叫"决定并行动"。

拆开看，它是几块 SQL 能力拼起来的：

原子入队：在标准读写事务里创建消息，与数据一起提交或一起回滚
定时投递：可以指定将来某个时刻才可见，延迟重试、定时回访不用再外挂调度器
租约加逐条确认：消费者取走消息后持有租约，处理完按条确认，租约到期后消息可以重新投递
SQL 拉取消费：用流式查询取消息，消费端不用再学一套新协议

因为消息就是表里的行，还有两个副作用：等待中的任务可以被 join、被过滤；"现在积压了多少、哪些超时了"这类问题能直接写 SQL 查，不必新建一套监控。

它补的不是吞吐，是"决定"和"行动"的裂缝

放到具体场景里看。一个 agent 干活是个循环：读状态、做判断、写回数据、排出下一步。前两步和后两步分属两个系统时，任何一次超时都能让循环停在中间，状态已经改了，任务却没排上，日志两边都不报错。

多 agent 协作时这个问题会被放大。A 交接给 B 的那一刻，交接记录和任务必须在同一个事务里落地，否则 B 可能拿着过期的上下文开工。官方博客里还提到，agent 的记忆落库和任务交接同样走这个事务，执行历史与记忆保持同步。

边界也要说清楚：它没打算在所有场合替代专门的消息系统。

队列的容量跟着你已有的计算实例走，数据库扛多少它扛多少。每秒几十万条埋点、日志这类纯事件流，仍然更适合专门的消息中间件；Spanner Queues 擅长的是"每件事都必须与某次状态变更绑在一起"的任务编排。名字相近的 Spanner change streams 也不是同一回事，那个是持续捕获数据变更给分析用，这个是可租约、可定时、可确认的任务编排。

两个最容易看错的地方

第一个看错：这就是"又一个消息队列"，选型上跟 Kafka 二选一。

这话有它的道理，它确实是队列，确实有投递、确认、重试。但它解释不了谷歌为什么非要把它塞进数据库：真正的差别不在投递本身，而在提交边界。Kafka 解决的是"事件怎么高效地流到下游"，Spanner Queues 解决的是"任务的产生和状态的变更怎么不脱钩"。更准确的理解是，它替换的不是 Kafka 的位置，而是那些"数据库加队列再加自己写的补偿对账"拼出来的胶水层。

第二个看错：有了 exactly-once，消费端就不用管幂等了。

有道理的地方在于，官方确实承诺每条消息按处理一次的目标交付，不丢也不重复投递。但这只在消息系统自己的范围内成立。如果你的消费者在确认之前调了外部接口，比如发邮件、扣款、调第三方，接口超时、消息被重投，副作用还是可能发生两次。更准确的理解是，这套语义把重复的概率压到了消息层，跨系统的幂等键仍然要你自己设计。