2454 积分	0 好友	324 主题

发消息

支付宝淘宝闲鱼支付异常复盘：消息队列故障与分布式事务状态不一致分析

发表于 2 小时前 | 查看: 4| 回复: 0

2025年12月4日晚，淘宝、支付宝、闲鱼等阿里系应用集体出现支付异常，核心症状是用户银行卡扣款成功，但订单状态却显示为“待付款”。这与2024年双十一期间支付宝的故障症状高度相似，其根本原因很可能指向了消息队列或分布式事务的协调问题。

截至本文发出时，相关官方仍未公布详细的技术原因说明。以下分析基于公开信息与技术原理，部分内容为推测，仅供参考。

发生了什么

2025年12月4日晚21点左右，淘宝、支付宝、闲鱼的支付链路开始出现异常。

淘宝支付宝崩了社交媒体评论截图

用户普遍反映，完成支付后，订单页面仍显示“待付款”；由于状态未更新，不少用户重复点击，导致同一订单被多次扣款。闲鱼客服排队人数一度超过9000人，微博热搜前十被“淘宝崩了”、“支付宝崩了”、“闲鱼崩了”等话题占据。此次故障持续了约两个半小时，至23:37左右基本恢复。

根据网络信息整理的粗略时间线如下：

约21:00：用户开始反馈支付宝付款异常，出现“银行卡已扣款，订单显示未支付”的情况。
21:41：米哈游《原神》官方发布公告，明确指出“由于支付宝服务异常，导致游戏出现无法充值、充值未到账问题”。
约22:00：三个“崩了”话题冲上微博热搜前十。
次日00:01：据第一财经报道，故障已修复。

影响范围：此次故障波及了整个阿里电商生态的支付链路，包括淘宝、支付宝、闲鱼、1688、饿了么、盒马等。同时，大量接入了支付宝支付的第三方应用也受到影响，《原神》是其中唯一在公告中明确点出问题根源的。阿里官方客服的回应主要是安抚用户“不要重复支付，系统稍后会更新”，但截至发稿，并未就技术原因作出任何说明。

原神官方关于支付宝异常的公告

似曾相识的症状

本次故障的核心症状非常典型：支付成功，但订单状态未同步更新。

这并非简单的“服务不可用”，而是更复杂的分布式系统状态不一致问题——支付服务认为交易已完成并扣款，但订单服务却未收到通知，导致状态滞后。用户看到“待付款”自然会尝试重新支付，从而引发重复扣款。

这个场景是否似曾相识？回顾去年，2024年11月11日（双十一当天上午），支付宝也曾发生过一次几乎一模一样的故障。症状同样是：银行卡扣款成功但订单显示未支付、同一订单被多次扣款、余额宝提现不到账。当时，支付宝官方给出了明确的故障原因：

支付宝去年故障通知提及系统消息库

“系统消息库出现局部故障”——这个官方措辞直接指向了消息中间件。在支付宝这类复杂的微服务架构中，消息中间件（如 RocketMQ）负责在各个服务间可靠地传递事务消息，是保障分布式事务最终一致性的关键枢纽。

问题可能出在哪里？

根据表现出的症状，我们可以先排除几种可能性：

不是风控误杀：如果是风控系统触发，用户通常会看到“交易风险提示”、“登录环境异常”等明确报错，而本次反馈中并无此类信息。
不是核心数据库宕机：如果订单或支付的核心数据库完全不可用，支付请求本身就会失败，不可能出现“扣款成功”的情况。
不是简单的网络中断：网络问题通常导致请求超时或完全失败，而非这种“一部分成功（扣款）、一部分失败（状态更新）”的割裂状态。

综合来看，最符合症状的解释仍然是消息队列或分布式事务协调机制出了问题。

支付宝普遍采用TCC（Try-Confirm-Cancel）分布式事务模型。简单来说，流程如下：

Try阶段：用户点击支付，支付服务冻结或扣减余额，订单服务将订单状态置为“处理中”，并向事务协调器注册分支事务。
Confirm阶段：当所有Try操作成功后，事务协调器触发全局提交，支付服务会发送一条“Confirm”消息（通常通过消息队列以半消息/事务消息形式发出），通知订单服务将状态更新为“已支付”。

问题就可能出在第二步。如果这条关键的Confirm消息因为某种原因未能成功投递或消费——例如消息队列本身故障、消费者处理能力不足导致消息积压、或事务回查机制超时失效——那么订单服务就永远收不到“支付成功”的通知，状态也就无法更新。

支付宝TCC分布式事务与消息队列故障点示意图

结合2024年双十一的官方归因和本次几乎复刻的症状，技术分析倾向于认为根因仍然与消息队列（RocketMQ）相关。可能是集群本身出现异常，也可能是上下游服务链路的某个环节（如订单服务消费端）因负载过高、资源瓶颈等原因处理缓慢，导致消息大量积压并最终超时。

此外，有技术社区注意到，阿里云官网发布了《云消息队列 RocketMQ 版 2025年12月升级公告》，其中计划在12月4日22:30至12月5日05:00对包括杭州、上海、北京在内的多个区域进行升级。虽然无法确认此计划运维操作与本次故障有直接关联，但时间点上的接近值得关注。

阿里云RocketMQ升级计划公告

反思与期待

支付系统是金融基础设施，用户将资金托付于此，对其稳定性和透明度的要求天然极高。在复杂的分布式系统中，故障难以完全避免，这一点是可以理解的。

但故障发生后的应对态度至关重要。2024年双十一，支付宝至少在故障后发布了声明，承认是“系统消息库”问题。而及时的透明度有助于维护信任。沉默往往滋生猜测，而猜测对信任的伤害有时比故障本身更大。

近年来，大型云厂商和互联网平台在发生重大故障后，发布详细的事后复盘报告（Post-Mortem）已成为一种惯例。报告会清晰阐述根本原因（Root Cause）、影响时间线（Timeline）以及后续的改进措施（Remediation）。对于本次涉及真实资金流转的支付链路故障，业界和用户都期待官方能给出一个清晰、及时的技术解释。