768台服务器,存着约1PB数据,应用程序只用一个连接地址就能访问全部。这是PlanetScale最近一篇工程博客给出的架构示例:256个分片,每个分片配1个主库、2个只读副本,凑出768台机器。
数字摆在那儿,像变戏法。但戏法拆开看,机关很直白:复杂度没有消失,只是换了个地方住——路由层、拓扑配置文件,和背后一支专职运维团队。
这篇博客的主角是PlanetScale自家的分片系统,MySQL用Vitess,Postgres用Neki,例子本身也带推销意味。但架构逻辑值得看懂,因为几乎所有做大规模应用的团队,迟早会撞上同一个问题:数据库撑不住了,下一步怎么办。
单机为什么扛不住,只读副本又为什么不够
单机数据库有三道天花板。
写入瓶颈:Postgres每次提交都要先写WAL并落盘,这是主库上所有连接共享的单一通道,加多少副本都绕不开。
容量瓶颈:副本是主库数据的完整拷贝,加副本不会分摊数据总量,只是多了几个读的出口。
备份瓶颈:数据量大了,备份到对象存储的带宽就是硬限制,几小时甚至几天都打不住,直接威胁RPO/RTO这两个恢复指标。
只读副本能救读请求扎堆,救不了另外两道墙。OpenAI公开提到过用50个只读副本撑一个主库的案例,规模已经很极限,写入瓶颈照样答不了。
| 方案 | 能解决 | 解决不了 |
|---|---|---|
| 只读副本 | 读请求扎堆 | 写入瓶颈、容量上限、备份时长 |
| 分片 | 写入分摊、容量横向扩展 | 跨分片事务、热点键、故障切换、扩缩容 |
原文给的分片时机是"几个TB以上",但这更像经验起点,不是行业定律。真正决定时机的,是写入量、查询模式、备份时效、硬件条件和团队的运维能力。同样是几个TB,一支只会用单机Postgres的团队,和一支常年跑Vitess的团队,该做的决定完全不同。
768台服务器怎么装成一台
数据摊到256个分片后,新问题冒出来:哪行数据存哪个分片?查询该发去哪台机器?跨分片查询怎么合并结果?这套调度压在一个叫路由器(router)的中间层上。
路由器不是简单的连接池。PgBouncer这类代理只负责把大量应用连接收拢成少量数据库连接。分片场景下的路由器还要多干几件事:解析SQL、做查询规划、管理连接池和缓冲、把跨分片结果聚合成一份返回给应用。
查询命中单个ID,路由器查一下内部映射,直接转发就行。但像WHERE id BETWEEN 3 AND 5这种跨分片的范围查询,路由器得自己算清楚该问哪几个分片、把结果聚合、再拼成一份返回。这意味着路由器内部要装下SQL解析器和执行计划生成器。
路由器怎么知道数据怎么分布?靠一份拓扑配置——Vitess叫VSchema,Neki叫data topology,写明哪张表按哪个字段分片、用什么哈希策略。这份配置文件本质上是把原来藏在应用代码里的分片逻辑,搬到路由层集中管理。
多个路由器怎么合并成一个入口?靠NLB(网络负载均衡)。应用只需要记住一个域名,DNS解析到NLB,连接进去后被分发给某个路由器,之后这条连接固定绑在这个路由器上。
应用侧最终看到的,还是一句熟悉的连接字符串。真实的256个分片、768台机器,全都藏在路由器和拓扑配置背后。
这对两类人意味着不同的动作。如果你是负责扩展Postgres或MySQL的数据库工程师,这篇博客真正的用处不在"该不该分片",而是提醒你先把账算清楚:写入量有没有真撞上单主瓶颈?备份时长有没有真打不住RPO/RTO?如果答案是否,加只读副本或者优化写入路径,大概率比重写整套数据访问层划算。
如果你是在评估分片中间件的技术负责人,真正要问的不是路由器技术先不先进,而是团队有没有能力长期运维一整套查询规划器、拓扑配置和跨分片故障处理。这活一旦上线就很难走回头路——迁移到分片架构,比迁回单机架构,难度不对称。
复杂度去哪了
秦并六国,书同文、车同轨,天下看着归于一统。但治理天下的复杂度没有消失,只是从列国分散,收拢进了中央官僚体系。分片系统和帝国行政终究是两回事,像三分不像十分,但结构相通:表面一个入口,复杂度归谁扛,才是真问题。
分片解决的从来不是"复杂度"本身,而是把它从应用代码里搬出来,集中到路由层、拓扑配置和一支懂这套系统的运维团队手里。这活不轻——跨分片事务、故障切换、扩缩容、256个分片同时做备份,每一项拎出来都是硬骨头。PlanetScale这篇博客对怎么解决这些问题,只字未提。
原文还提到AI适合帮着写和优化拓扑配置这类JSON文件,听着顺理成章,但没给任何效果数据或生产验证,当一句顺手带过的设想看就好,别当结论用。
分片也不天然带来更高的一致性或可用性。它换来的是横向扩展能力,代价是运维复杂度从"你看得见"变成"你看不见,但有人在扛"。
接下来最该盯的,是PlanetScale会不会公开跨分片事务和故障切换的实际方案。这篇博客只讲了"分好之后长什么样",没讲"出故障之后怎么办"——这才是分片系统真正的试金石。
复杂度没有消失,只是换了个地方住,而且换到了一个大多数团队现在还看不见的地方。