复盘肯德基全国级宕机事件.技术推测

大家好,我是老杨

肯德基出事了.

2026 年 1 月 22 日，“疯狂星期四”。本该是朋友圈疯狂刷屏“V 我 50”的狂欢，结果却变成了一场全国范围的技术灾难。

从昨天傍晚 18:00 开始，全国各地的写字楼和社区里，无数点餐手速飞快的朋友都卡在了同一个界面——“前方拥挤”或“系统维护”。

这不仅仅是 App 的问题。根据各方反馈，这次故障是全链路、全平台、全服务的深度瘫痪：

自有阵地全灭：App、微信小程序点餐功能在 18:00 - 20:00 的黄金时段彻底卡死。

外卖渠道停摆：美团、饿了么等平台上的肯德基门店集体“被动打烊”。

服务链条断裂：在线客服连不上，官方 400 电话被打爆。

最让用户崩溃的是，很多人钱付了，订单却没生成。这就很有意思了：钱去了哪儿？鸡又在哪儿？

肯德基倒下的同时，必胜客的外送也跟着瘫痪了一个多小时。

估计百胜中国业务中台的隔离机制存在硬伤。核心业务模块（比如鉴权、统一库存）可能缺乏有效的“熔断器”。当肯德基的超量请求把中台线程池占满后，同属一个架构的必胜客只能跟着陪葬。这种“不求同日生，但求同日死”的架构，在生产环境下是非常危险的。

大量扣款成功但无订单记录的客诉。

在老杨看来这是典型的分布式事务一致性冲突。在极端负载下，支付网关的回调通知发过来了，或许是订单中心因为数据库 I/O 达到瓶颈?之类的某种故障，没能在规定时间内确认收据。系统逻辑可能判定为“超时”，于是钱收了，单子却被丢进了虚空。

先确定收钱,再去派单.逻辑是没毛病的.

我看有大拿说业务侧可能只有2万的并发?

但是他没说这个2万并发是哪里的并发限制.

可能是业务门户节点没有做并发限制,但是内部并发打满导致业务能进来,但是处理不了?

感觉不太对,老杨跟怀疑是后端某个环节先出问题了.导致前端业务不行了.跟并发关系不大.

消息中间件挂了?或者某个业务库挂了.

这些玩意都得断业务,然后前后回滚,对齐数据.

要不然肯德基的技术团队也不会抢修了6小时，23日核心功能才逐步恢复，退款处理周期推迟至72小时.

不太相信肯德基能被正常流量打死~

不过肯德基挂了,可给麦当劳忙坏了。

老杨的另一个号欢迎关注