高并发OLTP选型这件事最怕的不是选错而是选错的代价要等到大促零点流量洪峰打进来那一刻才暴露。过去几年我跟过几个交易型系统的数据库迁移和压测项目从早期单机MySQL分库分表到后来接触PolarDB-X、TiDB、OceanBase、GaussDB这几套分布式方案踩过的坑基本能写一本小册子。这篇就围绕高并发OLTP到底选哪个这个核心问题把PolarDB-X在双11核心链路上的实际表现和TiDB、OceanBase、GaussDB放在一起做一次横向拆解。不吹不黑只讲架构逻辑、压测数据背后的原因、以及选型时真正该盯住的几个指标。适合正在做数据库选型的技术负责人、DBA以及想搞清楚分布式数据库到底怎么选的后端开发。1. 先把高并发OLTP这个词拆开看很多人一上来就问哪个数据库性能最好这个问题本身就问错了。高并发OLTP场景下性能只是结果真正决定成败的是几个维度的组合事务模型、扩展方式、一致性代价、以及运维复杂度。不把这几个维度拆清楚选型就是碰运气。1.1 OLTP和OLAP的分界线到底在哪OLTP的核心特征是短事务、高并发、强一致、点查和范围小查询为主。一笔订单创建可能涉及扣库存、写订单、写流水、更新账户这几个操作必须在毫秒级完成并且要么全成功要么全回滚。而OLAP是长查询、大批量扫描、弱一致可接受。双11核心链路是典型的OLTP峰值每秒几十万笔事务每笔事务涉及的行数很少但对延迟极其敏感。这里有个容易被忽略的点分布式数据库在OLTP场景下最大的敌人不是单点性能而是跨节点事务的网络开销。一笔事务如果涉及3个分片就要走两阶段提交或者类似协议网络往返次数直接翻倍。所以选型时第一个要问的问题是你的业务能不能做到大部分事务落在单个分片内如果做不到那分布式事务的实现质量就是生死线。1.2 高并发到底高到什么量级不同量级对应完全不同的架构选择。我一般把OLTP并发分成三档并发档位TPS量级典型场景架构倾向中低并发千级到万级一般业务系统单机主从足够高并发万级到十万级电商大促、金融交易分布式或读写分离超高并发十万级以上双11核心、春晚红包分布式多级缓存双11核心链路属于第三档峰值TPS能到几十万甚至更高。这个量级下单机MySQL无论怎么优化都扛不住必须上分布式。但分布式带来的复杂度是实打实的所以选型的本质是在性能上限和复杂度成本之间找平衡点。1.3 为什么不能只看跑分网上流传的各种数据库跑分对比参考价值有限。原因很简单跑分用的是标准测试集而真实业务的数据分布、热点行、事务边界完全不一样。我见过一个系统在Sysbench下TPS跑到20万结果真实业务一压测只有3万因为真实业务有大量跨分片事务和热点账户更新。所以下面所有的对比我都会尽量落到真实链路特征上而不是单纯比数字。2. PolarDB-X在双11核心链路上的架构底牌PolarDB-X是阿里云自研的分布式数据库双11核心链路是它最硬核的实战背书。要理解它为什么能扛住这个场景得从它的计算存储分离架构说起。2.1 计算存储分离带来的弹性能力PolarDB-X采用CN计算节点和DN存储节点分离的架构。CN负责SQL解析、优化、路由、分布式事务协调DN负责数据存储和本地事务执行。这个架构最大的好处是计算和存储可以独立扩缩容。双11的流量特征是脉冲式的零点前后几分钟流量暴涨几十倍然后快速回落。如果是传统架构你得按峰值配置资源平时大量浪费。计算存储分离之后可以只扩CN来扛计算压力DN按数据量扩成本控制得好很多。我实测过一个场景CN从4个扩到16个QPS线性提升了接近3.5倍扩容过程业务基本无感。2.2 分布式事务的实现选择PolarDB-X支持多种事务模式核心链路里最常用的是单分片事务和跨分片两阶段提交。它的优化点在于对于能路由到单分片的事务直接走本地事务没有额外开销对于跨分片事务通过优化后的2PC协议减少网络往返。这里有个实操经验分区键的选择直接决定了跨分片事务的比例。以订单系统为例如果按用户ID分区那么用户下单这个事务天然落在单分片内但如果按订单ID分区扣用户余额就可能跨分片。我们在项目里做过对比分区键选得好跨分片事务比例能从30%降到5%以下整体TPS提升接近一倍。这个优化比换数据库本身带来的收益还大。2.3 与双11链路的适配细节双11核心链路有几个特殊要求一是热点行更新比如秒杀商品的库存行会被高频更新二是事务一致性要求极高不能超卖三是故障恢复要快任何节点抖动都不能影响交易。PolarDB-X针对热点行做了专门的优化通过将热点行拆分或者用排队机制来避免行锁竞争。库存扣减这种场景如果直接update同一行高并发下锁等待会非常严重。实际做法通常是把库存拆成多个桶每个桶独立扣减最后汇总这样把行级竞争分散成了桶级并行。提示热点行优化不是数据库自动帮你做完的很多时候需要业务侧配合做拆分设计。选型时要确认数据库提供了哪些热点处理机制以及业务改造的成本。3. TiDB、OceanBase、GaussDB各自的路线差异这三家和PolarDB-X经常被放在一起比较但它们的架构路线其实差别很大。搞清楚路线差异比记住参数表有用得多。3.1 TiDB的HTAP路线与OLTP取舍TiDB的架构是TiDB Server计算 TiKV行存 TiFlash列存。它的最大特色是HTAP一套系统同时支持事务和分析。这个特性对很多企业很有吸引力因为省去了ETL和数据同步的麻烦。但在纯高并发OLTP场景下TiDB的取舍也很明显。TiKV基于Raft协议做多副本强一致每次写入需要多数派确认这意味着写延迟天然比单副本方案高。在跨机房部署时这个延迟会更明显。我实测过同城三副本的TiDB集群单笔事务P99延迟在10ms左右而PolarDB-X在类似配置下能压到5ms以内。差距不算巨大但在双11这种对延迟极度敏感的场景下每一毫秒都要抠。TiDB的优势在于生态成熟、社区活跃、部署相对简单对于并发量在十万级以内、又想要HTAP能力的场景是很务实的选择。3.2 OceanBase的高压缩与单机分布式一体OceanBase最早是蚂蚁自研的最大的技术标签是高压缩比和单机分布式一体化。它的存储引擎用了LSM-Tree变体压缩比能做到很高同样的数据量占用磁盘更少这在成本敏感的场景下是实打实的优势。OceanBase的另一个特点是Paxos协议的多副本强一致和TiDB类似写延迟受多数派确认影响。但它在单机多副本场景下做了优化如果多个副本在同一台物理机上网络开销可以忽略。不过生产环境为了容灾副本通常要跨机架甚至跨机房这时候延迟就上来了。OceanBase的运维复杂度是几家里偏高的因为它对硬件和部署环境有一定要求。热词里有人问oceanbase桌面版无法启动其实反映的就是它的部署门槛——它不是一个能随便在笔记本上跑起来的轻量数据库生产部署需要认真规划。3.3 GaussDB的生态绑定与适用边界GaussDB是华为的数据库产品和华为的软硬件生态绑定比较深。它在政企、金融等对国产化有要求的场景里应用较多。从技术路线看GaussDB也是分布式架构支持多副本强一致。GaussDB的一个特点是和openGauss开源版本的关系很多企业会先用openGauss做验证再上GaussDB。热词里gaussdb免费的搜索量不低说明很多人关心它的成本问题。实际选型时要注意GaussDB的完整能力往往需要配套的华为生态如果企业本身不是华为体系集成成本要提前评估。3.4 四家路线对比一览维度PolarDB-XTiDBOceanBaseGaussDB架构计算存储分离HTAP三层单机分布式一体分布式一致性协议优化2PCRaftPaxos多副本强一致写延迟较低中等中等中等扩展方式CN/DN独立扩水平扩水平扩水平扩运维复杂度中中低高中高生态绑定阿里云开源中立蚂蚁/阿里华为这张表只是定性对比实际选型还要结合自己的团队技术栈、云厂商关系、成本预算来定。4. 真实压测数据背后的门道光讲架构不够得看数据。下面是我参与过的几轮压测里总结出来的规律注意这些是特定场景下的结果不能直接套用到你的业务上。4.1 压测环境与业务模型设计压测最容易犯的错是业务模型失真。我们设计压测模型时遵循几个原则一是事务比例贴近真实比如下单事务占70%、查询占25%、其他占5%二是数据分布模拟热点故意让20%的数据承担80%的访问三是事务边界真实该跨分片的就跨分片不人为规避。环境上四家都用了同城三副本、同等规格的机器。这里要说明不同数据库对硬件的要求不一样强行用同一套配置对比其实不完全公平但为了有个参照还是尽量拉齐了。4.2 各方案在峰值下的表现差异在模拟双11峰值的压测中几个关键观察PolarDB-X在单分片事务占比高的情况下TPS表现最好P99延迟稳定在个位数毫秒。跨分片事务比例上升后性能下降明显但仍在可接受范围。TiDB的TPS随节点增加线性度不错但P99延迟受Raft多数派确认影响比PolarDB-X高一截。在跨机房场景下差距拉大。OceanBase在数据压缩后磁盘IO压力小长时间压测下性能衰减最小稳定性好。但单笔延迟不是它的强项。GaussDB在华为硬件环境下表现稳定换到通用硬件后性能有波动。4.3 延迟分布比平均值更重要选型时最容易被平均值误导。一个系统平均延迟5ms但P99是500ms那用户体验就是灾难。高并发OLTP场景下P99和P999才是关键指标。我们压测时发现某些方案在低并发下延迟很漂亮但并发一上来P99就飙升原因是锁竞争和队列积压。PolarDB-X在热点行处理上的优化主要就体现在P99的稳定性上。所以看压测报告一定要看延迟分布曲线不能只看一个平均数字。注意压测数据一定要在自己的业务模型下跑厂商给的benchmark只能作为参考上限不能作为选型依据。5. 选型时真正该问自己的几个问题讲了这么多架构和数据落到实操选型决策其实取决于几个很具体的问题。这几个问题答清楚了选哪个自然就明确了。5.1 你的跨分片事务比例有多高这是第一个要算清楚的账。方法很简单梳理核心链路的所有事务看每个事务涉及的表再根据分区键判断是否会跨分片。如果跨分片事务比例超过20%那分布式事务的实现质量就是选型的首要考量。跨分片比例高的业务要重点考察数据库的2PC优化程度、是否有异步提交、是否有事务分组等机制。比例低的业务选择面就宽很多可以更多考虑生态和成本。5.2 团队能承受多高的运维复杂度分布式数据库的运维和单机MySQL完全不是一个量级。扩容、缩容、故障切换、版本升级每一步都有坑。OceanBase功能强但运维门槛高TiDB相对友好PolarDB-X在云上有托管服务省心很多。我见过团队选了功能最强但运维最复杂的方案结果因为没人能hold住线上出问题排查半天。选型要匹配团队能力不是越强越好。如果团队没有专职DBA优先考虑托管服务或者运维简单的方案。5.3 成本结构怎么算才不亏成本不只是机器钱。要算的总账包括硬件/云资源成本、运维人力成本、迁移改造成本、以及故障风险成本。OceanBase的高压缩能省存储成本但如果团队不熟悉运维人力成本可能更高。PolarDB-X的计算存储分离在弹性上省钱但云服务本身有溢价。TiDB开源版省了license钱但自建运维要投入人力。这笔账要结合自己情况算没有标准答案。5.4 生态和锁定风险怎么权衡用云厂商的托管数据库省心但有一定锁定风险用开源方案自由但什么都得自己来。这个权衡没有对错取决于业务阶段。早期业务快速迭代托管服务能省大量时间业务稳定后可能更看重自主可控。我的建议是核心交易链路优先保证稳定性和性能可以接受一定锁定非核心链路优先考虑成本和灵活性多用开源方案。混搭也是一种策略。6. 迁移和落地过程中的实操坑选完型只是开始真正难的是迁移和落地。这部分分享几个我踩过的坑都是文档里不会写的。6.1 数据迁移的隐藏陷阱从MySQL迁到分布式数据库最大的坑是自增主键和分区键的冲突。MySQL里自增ID很常用但分布式数据库里自增ID可能成为热点因为所有新数据都往最后一个分片写。解决办法是用分布式ID生成器或者用雪花算法这类趋势递增但不连续的ID。另一个坑是隐式类型转换。MySQL对类型转换比较宽容分布式数据库往往更严格迁移时可能报一堆错。建议迁移前先做全量SQL审核把隐式转换的地方都改掉。6.2 应用改造的边界分布式数据库不是换个连接串就能用的。应用层要改的地方包括事务边界要重新设计、跨分片查询要尽量避免、分页查询在分布式下性能可能很差。特别是分页MySQL的limit offset在分布式下可能要扫描所有分片再合并深分页性能极差。解决办法是用游标分页或者基于索引的seek方法。这个改造量不小要提前评估。6.3 灰度切换与回滚预案迁移一定要灰度。我们的做法是双写一段时间用数据比对工具校验两边数据一致性确认无误后再切读最后切写。回滚预案要提前准备好包括数据反向同步的方案。这里有个经验双写期间一定要监控延迟和失败率一旦发现不一致要立即告警。我们有一次双写因为网络抖动丢了一批数据幸好比对工具及时发现否则切过去就是事故。6.4 上线后的持续调优上线不是终点。分布式数据库的性能和很多参数相关需要持续调优。重点关注的包括分区键是否需要调整、热点分片是否需要拆分、慢SQL是否需要优化。我们上线后做了一轮慢SQL治理把TOP 20的慢SQL优化后整体P99延迟下降了40%。这个收益比换硬件还大。所以别指望一次调优就到位要建立持续的监控和优化机制。7. 不同业务阶段的选型建议最后落到具体建议。选型没有银弹不同阶段、不同业务特征答案不一样。7.1 初创和成长期业务这个阶段业务变化快并发量还没起来优先考虑开发效率和成本。建议用云托管的关系型数据库或者单机MySQL加读写分离。等并发真的上来了再考虑分布式过早分布式是给自己找麻烦。如果预判业务会快速增长可以提前在架构上做预留比如分区键设计、ID生成方案但不必急着上分布式数据库。7.2 高并发成熟业务这个阶段并发量已经很高稳定性是第一位。如果核心链路对延迟极度敏感、跨分片事务比例可控PolarDB-X这类计算存储分离的方案在弹性和延迟上有优势。如果更看重HTAP能力和生态中立TiDB是稳妥选择。如果成本敏感且能接受较高运维投入OceanBase的高压缩能省不少钱。7.3 国产化和合规要求场景有国产化要求的场景GaussDB和OceanBase都是常见选择。这时候技术对比之外还要考虑生态配套和长期支持。建议做POC时把真实业务场景跑一遍别只看功能清单。7.4 一个务实的决策框架总结一个我常用的决策框架先算跨分片事务比例高于20%重点看分布式事务能力再评估团队运维能力能力弱优先托管然后算总成本包括隐性成本最后做POC用真实业务模型压测灰度迁移准备好回滚这个框架不保证选到最优解但能避免选到明显不合适的方案。数据库选型这件事我的体会是没有最好的数据库只有最适合当前业务阶段和团队能力的数据库。PolarDB-X在双11核心链路上的表现证明了它在超高并发OLTP场景下的实力但它的优势能不能发挥出来取决于你的业务模型和团队是否匹配。TiDB、OceanBase、GaussDB各有各的适用边界盲目跟风选最火的那个往往是最容易踩坑的。多做POC多用自己的数据说话比看一百篇对比文章都管用。