Google Cloud在2026年9月17日宣布Spanner queues正式商用。该能力把队列建在Spanner表与事务机制之上，应用可以在写入业务数据的同一笔事务中插入消息，再由接收器通过SQL接口拉取并处理。
它适合需要确保“业务数据提交后才产生异步任务”的场景，例如订单后续步骤、延迟任务和外部通知。不过，Spanner queues仍采用至少一次投递，消费者必须按可能重复收到消息来设计。
事务消息解决了数据库与队列的双写问题
应用可以用标准DML或Mutation API把消息写入队列，并与其他数据库修改放在同一笔Spanner事务里。如果事务回滚，消息也不会进入可投递状态，从而避免业务记录失败但队列任务已经发出的不一致。
消息确认同样可以通过DELETE或Mutation API放进事务。原子性覆盖的是Spanner内部的数据和队列操作，不会自动把外部HTTP调用纳入同一事务，调用第三方系统仍需幂等或补偿机制。
消费依赖流式SQL、确认和租约续期
队列需要包含Payload列和主键。接收器使用ExecuteStreamingSQL调用系统生成的RECEIVE函数，以长查询方式拉取消息；处理完成后再删除消息或调用确认API。
处理时间可能超过租约时，应调用RENEWLEASE函数延长租约，否则消息会在租约超时后重新投递。消费者必须把续租、确认与失败重试作为一套流程实现，只调用接收函数并不能保证任务只执行一次。
至少一次投递不等于恰好一次执行
Spanner queues保证至少一次投递，因此网络中断、进程崩溃或租约到期都可能让同一消息再次出现。事务确认可保证一条消息最多被成功确认一次，但这与业务副作用只发生一次并不相同。
发送邮件、扣减外部余额或调用其他服务时，应使用稳定消息ID、幂等键和处理结果表去重。如果消费者不具备幂等性，正式商用状态也无法消除重复执行风险。
版本、并发和队列数量都有明确限制
该功能仅提供给Spanner Enterprise与Enterprise Plus版本。每个队列使用相同参数的活动接收查询最多1000个，每项目每区域的并发接收TVF默认配额为2000个。
拥有一个或更多节点的实例最多创建100个队列，细粒度实例会按计算单元比例缩减；队列不能建在命名schema中，也不支持AddSplits手动切分。它不是无需容量规划的无限队列服务，高扇出消费应先计算并发与配额。
何时选队列，何时仍该使用变更流
Spanner queues适合事务事件通知、未来定时任务以及需要逐条确认的短消息。消息作为行可查询、过滤和连接，也能随Spanner计算资源扩展，适合与数据库状态紧密耦合的异步工作。
如果目标是高吞吐复制、同步下游缓存或索引、记录每次数据库变更，官方仍建议使用change streams。上线验收应同时检查重复投递、租约超时、积压增长、消费者延迟和配额余量，而不是只验证消息能够入队。
