如何应付每秒三万个写请求

最近在知乎看到一个问题：每秒3万支付订单请求，技术栈是Oracle、Java、Spring、MyBatis、Dubbo、MQ，主要矛盾是高并发写，该从哪下手？

其实这个问题最重要的要解决的就是：写瓶颈的问题。

这篇按三条线展开：

• 我们以前用分库缓解写压力；
• 2026年分布式数据库可以纳入研究；
• 国内大厂有哪些公开做法。下面依次说。

分库是我们的解法

十多年前，我参与过一个电商系统的分库改造。当时用的是MySQL，不是Oracle。

分库的直接原因，是MySQL单实例能承接的写TPS有上限。我记得当时，一个实例写的TPS差不多在1.2万左右。公司大促下单峰值2000，当时架构还能撑，按业务增速估算，很快会顶到天花板。

架构师拍板做分库，并且一次性规划了168个MySQL实例，目标是满足未来10年的业务发展。按单实例1.2万写TPS粗算，168个库在写扩展上留了足够余量。

这是一次大型技术专项，单独立项，周期半年多，前三次上线都失败了，第四次才成功。涉及双读双写、数据质量、一致性校验。订单数据往下游结算、履约、库存系统流转，一出错就是生产故障，数据还很难修。

到2026年，还是这168个库在跑，依然能支撑业务。Oracle单实例能写多少，我没有一手数据，且不熟悉Oracle，不过有一条通用规则：写的并发请求过大时，必须想办法缓解，分库是路径之一。

订单支付主链路为什么不建议队列削峰

有人会用MQ做削峰。核心的订单支付等系统我不建议这么干。

比如创建订单的链路里有扣减库存、扣减优惠券。用户提交后要尽快知道结果，库存和券的状态也要和业务一致。请求先进队列、异步落库，用户侧等待时间变长，中间态变多，出问题时排查链路也拉长，对用户体验也不好。

MQ更适合解耦，下游通知这类场景，不太适合拿来抗核心交易系统主链路的写压力。

分布式数据库值得研究

168物理分库在2026依然有效，但是毕竟是10多年前的方案了。云原生分布式数据库提供了另一条路：把分片、路由、部分分布式事务纳入产品里。

两条路径解决的是同一个问题，不是非此即彼。2026年新建系统，我会先评估分布式库能否把168实例的运维复杂度收拢，而不是默认复制168库方案。已有168库且运行稳定，换库的收益要和一次性迁移成本放在一起算。

下面几条来自各产品官网或官方文档，不是我实测结论。选型仍要做自家概念验证（业内常叫POC，Proof of Concept，即用接近生产的场景试跑，看能不能扛住你的表结构和流量）。

OceanBase：官网写明面向金融、运营商等高并发交易场景，官方称曾在TPC-C基准测试中刷新纪录，并在蚂蚁集团内部核心交易与双11大促中长期使用。这里的双11指阿里/蚂蚁体系内的生产验证，不是你的业务能直接复现同等峰值。官网也强调兼容MySQL与Oracle、金融级高可用，写密集且强一致诉求高的场景通常会纳入评估名单，基准数字只能作参考。

TiDB：TiDB文档首页自定位为HTAP融合型分布式数据库，兼容MySQL协议与MySQL生态。跨机房容灾方面，官方提供跨数据中心部署拓扑和双区域多AZ方案。交易和实时分析都要的场景，可以纳入概念验证候选。

PolarDB-X：PolarDB-X官方文档定位面向超高并发写、海量存储的Shared-nothing分布式库，采用存储计算分离，最初为天猫双11核心交易扩展而设计。要和PolarDB产品概述分开看：PolarDB MySQL版是共享存储、一写多读架构，阿里云开发者社区问答中也提到其写入能力受主节点规格约束，更适合写压力在单机承受范围内的场景。PolarDB-X才是分库分表、水平扩写的路线。

GoldenDB：中兴GoldenDB金融应用指南（PDF）写明面向金融核心系统等场景。公开信息里，运营商侧有中国移动、中国联通集采落地，金融侧有多家银行理财核心类案例。政企、金融行业选型时可对照同类型公开案例，不能替代自家概念验证。

国内大厂公开做法

下面链接都是公开文章，我按公司整理，方便你对照看。文里的峰值、分库规模是特定年份和场景下的数据，不能直接套到你的系统上。

我只是提供出来，让你多一种思路而已。

阿里/蚂蚁

支付写扩展，蚂蚁公开材料里反复出现两个东西：**单元化（LDC）**把流量和数据按用户维度拆到不同逻辑单元；**分布式库（OceanBase）**在单元内承接高并发写。

• 金融级单元化分布式架构的设计原理与实践案例（阿里云开发者社区）：RZone/GZone/CZone单元划分、三地五中心、分片五副本，讲单元封闭与异地多活怎么搭。
• OceanBase2.0让百万支付不是梦？（阿里云开发者社区）：支付核心链路从百库百表到按UID分区扩展，说明写瓶颈上来之后怎么继续拆。
• 蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践（InfoQ）：LDC逻辑机房、蓝绿发布、全链路压测摸高，文中提到花呗链路压测得到每秒约4万笔支付的处理能力（特定年份压测结果）。
• 支付宝背后的OceanBase：国产自研分布式数据库这十年（InfoQ）：2015年交易库和支付库迁到OceanBase的时间线，以及双11峰值数据的公开表述（文章发布年份不同，数字与上文可能不一致，以原文为准）。

美团

订单写扩展，美团技术团队公开文章的重点是：水平分库分表、多查询维度冗余存储、双写+对账迁移。

• 大众点评订单系统分库分表实践（美团技术团队）：32×32分库分表、UserId/ShopId切分、订单号自带路由规则，以及双写迁移三阶段（对账、切读、停写老库）。
• 美团外卖订单中心的演进（美团技术团队）：单库写容量到顶后按订单ID、用户ID、门店ID各存一份，应用层分库分表插件，避免把分片逻辑散落到业务代码里。

京东

京东公开可核验的分库分表材料，Apache ShardingSphere官网这篇是京东白条团队参与撰写的落地复盘。

• Apache ShardingSphere在京东白条场景的落地之旅（ShardingSphere官网）：千亿级数据分片、近万个数据节点、Hash分片避热点、约4周割接过程。场景是信用支付（白条），不是商城主站订单库，但分库分表方法论可对照。

字节跳动

字节公开材料里，和「高并发写+多单元」直接相关的是单元化架构；数据库侧是veDB/ByteKV等自研存储，和MySQL分168库不是同一条路，但扩容思路值得看。

• 单元化架构在字节跳动的落地实践（InfoQ）：抖音、抖音电商、抖音支付等接入异地单元化；文中明确写到支付类业务对一致性要求高、跨Region强一致数据库需求强。
• 字节跳动数据库的过去、现状与未来（字节跳动基础架构，微信公众号）：veDB计算存储分离、计算层无状态弹性扩缩、存储层多副本强一致，属于另一条技术路线。

小结

每秒3万支付请求，写压力必须缓解。我们当年用168个MySQL实例分库扛写，至今仍在跑；订单主链路不建议用MQ削峰。2026年PolarDB-X、TiDB、OceanBase等分布式库可以纳入研究，概念验证要带真实表结构，不能只看厂商峰值数字。阿里、美团、京东、字节都有公开文章可查，上文已按公司整理链接，建议按自家场景选读。

参考的内容

• OceanBase官网
• TiDB文档中心
• TiDB跨数据中心部署拓扑
• PolarDB-X官方文档
• PolarDB产品概述（阿里云）
• PolarDB MySQL版与PolarDB-X区别（阿里云开发者社区）
• GoldenDB金融应用指南（中兴官方PDF）

最近在知乎出了

• 「应付6000万会员的秒杀系统专栏」
• 「几亿用户,百万并发的C端商品系统实战」
• 「技术团队DDD领域驱动设计三年落地实战」
• 「应付亿级用户规模的支付系统代码实战」
• 「应付亿级用户的会员体系代码实战」
• 「我的项目管理实战手记：10个真实主导项目，还原实战现场」
• 「9年团队管理实战」

专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：

• 老码头的技术浮生录

它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」

当前星球里免费看的专栏是：

• 「应付6000万会员的秒杀系统专栏」
• 「几亿用户,百万并发的C端商品系统实战」
• 「技术团队DDD领域驱动设计三年落地实战」
• 「应付亿级用户规模的支付系统代码实战」
• 「应付亿级用户的会员体系代码实战」
• 「我的项目管理实战手记：10个真实主导项目，还原实战现场」
• 「9年团队管理实战」

知识星球内后续将推出20+个付费专栏，覆盖电商全链路：

从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。