PolarDB：当数据库成为业务瓶颈，问题到底出在哪？
容易忽略的细节
PolarDB看似简单，真正落地时却很容易踩坑。你一定遇到过这样的场景：双11大促刚开始，后台监控里数据库的CPU瞬间飙到100%，写入延迟变得不可接受，甚至因为锁冲突导致整个系统卡死。传统的单体数据库——无论是自建的MySQL还是商业数据库——都面临同一个核心矛盾：计算和存储绑在一起。每个数据库实例既要管CPU计算（处理SQL、事务、日志），又要管磁盘I/O（读写数据文件、redo log）。当写入压力增大，所有资源都在一台机器上抢，扩容只能通过垂直升级（换更强的硬件），成本高且总有上限。
阿里云PolarDB的诞生就是为了解决这类场景。它采用计算与存储分离（简称存算分离）架构，把“计算”和“存储”拆成独立的资源池，通过高速网络连接。这个思路听起来简单，但实现细节决定了它能承受多大的并发写入，以及如何支持读写分离的弹性扩展。
存算分离到底是什么？打破传统的“夫妻店”模式
传统架构：计算和存储“挤在一间房里”
在传统MySQL主从架构中，主库负责所有写入，从库负责只读查询。但主库本身仍然是一台完整的服务器：CPU处理查询和日志，内存做缓存，本地硬盘存数据文件和事务日志。写入一条数据，主库要做：写入InnoDB buffer pool、写redo log、写binlog、刷盘……所有I/O操作都在本地磁盘。一旦并发写入升高，磁盘带宽成为瓶颈，CPU空转等待I/O，性能断崖下跌。
存算分离：计算节点和存储节点“各管各的”
PolarDB把数据库实例拆成两层：
- 计算节点（Compute Nodes）：负责SQL解析、事务处理、查询优化、内存缓存。不存数据文件，只有本地缓存。
- 存储节点（Storage Nodes）：由多台机器组成分布式存储集群，使用高可用分布式文件系统（PolarFS），持久化数据文件和redo log。存储节点之间通过多副本保证数据不丢。
计算节点和存储节点通过高速RDMA网络通信。写入时，计算节点只把redo log推给存储节点，由存储节点负责实际的数据页写入和刷盘。这样，计算节点彻底解放了磁盘I/O的负担，可以更专注地处理CPU密集型任务。
关联教程：此处可内链到“PolarDB部署与验证”内容。
高并发写入怎么做到的？物理复制与并行回放的协同
很多读者会问：光把存储搬出去，就能扛住高并发写入吗？真正关键的是写入路径的重构。
传统写放大问题
传统MySQL中，每次写入至少写两份日志（redo+binlog），还要写数据页，并且需要保证crash-safe，操作复杂。高并发时，写冲突、锁竞争、日志同步都会降低吞吐。
PolarDB的优化：redo日志下沉到存储
PolarDB采用类似Oracle RAC的共享存储机制：所有计算节点（包括主节点和只读节点）共享同一份存储数据。主节点写入时，只把redo log发送到存储集群，存储节点上的日志回放进程（PolarDB特有的replay机制）在后台将redo应用到数据页。这意味着：
- 主节点写入延迟极低：只需要一次网络发送（发送redo到存储），无需等待真实数据页刷盘。
- 存储节点批量合并写入：多个小写入在存储层合并成大I/O，提升磁盘利用率。
- 物理复制替代逻辑复制：传统主从复制要传输SQL语句或row-based binlog，需要重新解析执行；PolarDB的只读节点通过读取共享存储上的redo log或数据页，直接获得最新数据，不需要额外传输。
这套机制使得PolarDB的单主节点写入性能可以达到传统MySQL的数倍以上，尤其适合写多读少的场景（如订单创建、日志写入）。
进阶阅读：此处可内链到“PolarDB性能优化”指南。
补充参考：此处可内链到“PolarDB故障排查实例”。
读写分离节点扩容：加个节点就能分担读压力
存算分离的一个巨大优势是读写节点可以独立弹性扩展。因为存储是共享的，任何新增的计算节点都能立刻访问到同一份最新数据。
从一对N的困惑说起
传统MySQL主从模式下，增加从库需要重建数据（全量备份+binlog追赶），耗时长（几小时甚至几天），而且从库和主库之间还有复制延迟。一旦写压力变大，从库可能跟不上主库的写入速度，导致读取到旧数据。
PolarDB的“零数据拷贝”扩展
在PolarDB中，添加一个只读节点（Read Only Node）只需要几分钟。因为：
- 不存在数据拷贝：存储已经在那里，新节点只需要挂载共享存储，读取数据页。
- 日志回放不消耗主节点资源：计算节点启动后，后台从存储节点并行回放最近的redo日志，很快就能追赶至最新状态。
- 写节点和读节点完全独立：主节点负责写入，只读节点负责复杂查询、报表分析、后台任务等，互不抢占CPU和内存。
操作方面，在阿里云控制台或通过API，你可以指定新增节点的规格（比如16核64G），自动加入集群的读写分离地址。应用程序只需修改连接串，或者利用PolarDB自带的读写分离功能（自动识别并路由到只读节点），即可享受弹性扩展。
想继续深入：此处可内链到“PolarDB优化清单”文章。
延伸阅读：此处可内链到“PolarDB配置案例”相关文章。
为什么需要这种架构？从云原生的角度看
先看关键判断
PolarDB的存算分离不是简单的堆硬件，而是为了适配云原生环境下的几个刚性需求：
- 资源解耦与按需付费：计算和存储可以独立扩缩容。业务增长时，你可以只增加计算节点（比如从2核升级到8核），存储容量不变；或只扩存储容量，计算节点不变。避免资源浪费。
- 高可用与快速故障恢复：如果主节点宕机，PolarDB会自动从只读节点中选举一个新主节点（基于共享存储，数据不丢），切换时间通常在30秒内。相比传统主从手动切换快很多。
- 支持混合负载：同一个集群可以同时承载高并发OLTP写入和多维分析查询，而不互相影响。
当然，存算分离也有代价：依赖高性能网络（RDMA）和分布式存储的稳定性。但在阿里云内部经过多年大规模验证，已经成为云数据库的标杆架构。
验证与最佳实践：该如何上手？与PolarDB
容易忽略的细节
如果你的业务正在面临数据库写入瓶颈或读扩展困境，可以这样尝试：
- 评估当前负载：监控你的数据库CPU、I/O等待、并发数。如果I/O等待占比高，而CPU利用率并不饱和，说明磁盘成为瓶颈，存算分离架构可能很有帮助。
- 选择合适的PolarDB规格：根据最大并发写入量和数据量，选择主节点规格和存储空间。刚开始可以选较小规格，后续在线升级。
- 启用读写分离：创建至少一个只读节点，并配置连接地址。在应用层将读操作指向只读地址，写操作仍用主地址。
- 观察延迟和扩展效果：通过PolarDB的监控仪表盘，查看主节点的写入延迟和只读节点的回放延迟。如果回放延迟持续增加，说明写太快但读节点处理不过来，可以升级只读节点的规格或增加节点。
需要特别注意的是：存算分离并不是万能的。如果你的数据量极小（比如几GB），传统单机数据库成本更低；如果你的查询全是点查询且极度依赖内存缓存，则可能享受不到存算分离的最大优势。但对于互联网高并发、海量数据场景，PolarDB无疑是当前最优解之一。
总结
我的处理经验
阿里云PolarDB通过将计算与存储分离，让写入路径从本地磁盘瓶颈转移到高速网络+分布式存储，实现了高并发下的低延迟写入。同时，共享存储机制使得增加只读节点无需数据拷贝，读写分离扩展成为分钟级操作。理解这些概念，能帮助你更好地规划数据库架构，在业务增长时游刃有余。
延伸阅读