震荡开局的2025双11：淘宝崩后，拼多多又崩了

IT知识刺客 2025-10-22

又是一起分布式导致复杂性失控的案例。但和淘宝双双在双十一前崩，这时间点挺有意思，从一定程度上说明分布式规模失控的后果，开始逐渐显现。

我在上一篇淘宝崩了：淘宝崩了：双11开启在即，淘宝先崩为敬中，将分布式分为有限分布式与无限分布式。

计算机整个体系从下到上，从芯片到上层应用，到处都是分布式。

自从二十年前摩尔定律逐渐逼近极限，从芯片开始，就已经在向分布式转型。

现在的CPU是典型的分布式系统，内存中有全量的数据，每个Core的L1 Cache 以Cache Line（通常是64字节，少量CPU是128字节）为单位，有内存数据的副本，且副本存在多个。因为多个Core可能有同一数据的副本。

这些副本间需要一致性机制保障一致性。这个多核间一致性保障机制叫MESI，本文定位“闲聊”，技术上不过多展开，你可以自行查阅MESI资料。这个MESI和一些分布式数据库要考虑的问题一样，甚至处理思路都十分相似。

如果你正在从事分布式数据库开发，你绝对可以从MESI收获一些灵感。

（我们以后在“基础软件开发”专栏，再展开聊MESI的实现、机制）

CPU MESI这种分布式就是有限分布式。它的分布式规模十分有限，在一块CPU内、一台主机内、一个操作系统内核中。

而基于以太网等“网络”技术，跨多台独立主机组成分布式，就是无限分布式。它当然不是无限，但分布式规模可以大很多。

整个世界的学术圈、技术圈，主要围绕有限分布式。

在有限分布式领域，CPU越来越”分布“，除了MESI，后来又有了NUMA。现在则正在向CXL方向，小心的尝试。

操作系统的”调度“，就是一个”有限分布CPU“的管理中心。

在数据库领域，图灵奖获得者、Stonebraker的DBOS项目，则剑指操作系统的“调度”，要革操作系统的命，用数据库接管“调度”，管理成百上千的Core和成千上万的进/线程。

商业的基础软件，如Oracle数据库，有无限分布的功能，但并非主要发展方向。

基于网络技术的无限分布式，更多停留在上层。比如我们都可以同时打开微信，这也是一种分布式。

注：再次强调，这里的网络技术主要指以太网等，实际上CPU的核间互联也是网络技术，但和以太网等有本质区别。

无限分布式不温不火的主要原因，明眼人都能看出来，网络延迟已经决定了无限分布式的上限。

如果一个操作总时间是0.1毫秒，其中硬件、通信成本是0.09毫秒，这是无法逾越的，软件层只能在0.01毫秒的螺蛳壳里做道场。

说直白点，硬件层占了90%的时间，软件层只占10%，对软件层而言，这就不是一个很好的发展方向。你的上限最多只能提升10%的性能，这就叫“没有想像空间”。

上限不高。

为了处理网络带来的不稳定性，复杂度又提升了一、两个数量级。Paxos协议不就是干这个事的吗，非常复杂。

上限不高，又非常复杂。

再看看有限分布式，至强6已经有128颗物理Core了，超线程后256 Core。配个双路，整机512 Core，再搭配个1TB内存，试问你是啥系统、有多大的并发、数据量，512 Core + 1TB内存满足不了。

有限分布式可以满足超过99%的需求。所以基础层主要的研究、商业产品，都是有限分布、而不考虑大规模跨网络无限分布。

512 Core真满足不了也可以考虑 4 路，2048 Core，够了吧。

但对于阿里、拼多多这种量级的互联网公司，其实也够。但是吧，也可能真不够。我的意思是，阿里、拼多多这种量级，是真的要考虑“不够”的可能。

还有Google，也要考虑不够。所以Google在20年前搞出来个“三驾马车”。整的国内分布式数据库高潮叠起，一浪胜一浪。动不动就是基于Google三驾马车，实现国内自主可控分布式数据库……。

然后还真有不少中、小型金融机构的数据库竟然真的“分布”了。也不想想，摩根士蛋利和高盛的数据库也没有使用三驾马车式的无限分布式。

分布式必需使用，但不能滥用。很明显前十几年，在国内分布式技术已经有滥用的趋势。

分布式滥用的后果，就是复杂度大大提升。也就是开篇所说：“复杂度失控”。

今年双11前两大巨头默契般的“两连宕”，正是这种复杂度失控的结果。更多复杂度失控的恶果，其实是“内部消化”了。（因为做为吃瓜群众，我们只能看到阿里、拼多多“两连宕”）

不过，现在已经有了改变的可能。AI兴起，分布式已经不再是热点，那些原来分布式“弄潮儿”，正在忙着往自己脸上贴AI“弄潮儿”的标签，打造AI+数据库。随着这批搅屎棍精力的转移，基础层架构也将回归理性（但会被搅入大模型的屎花）。

文章转载自IT知识刺客，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。