2019年双十一，阿里云主库被打爆，大量用户支付失败。故障根因：只有一台数据库，所有读写全挤在上面。三年后，同样的问题让另一家大厂中招。主从数据库架构，正是解决这个问题的标准答案。

主从数据库：为什么你的系统每次大促都"死"在同一个地方

2019年双十一，阿里云发出故障公告：主库被打爆，大量用户支付失败。 故障根因说出来你可能不信——数据库只有一台，所有读写全挤在上面。那一年，阿里紧急对数据库做了主从分离，之后连续三年大促平稳度过。

这个故事说明了一个很多人不愿意承认的事实：大多数系统不是死于复杂的架构问题，而是死于"一台数据库打天下"的朴素选择。 今天聊的主从数据库架构，正是解决这个问题的标准答案。

主从架构是什么

主从数据库，核心逻辑就一句话：一个主库（Master）专门写，多个从库（Slave）专门读。

主库处理所有写操作——新增、修改、删除。从库复制主库的数据，处理所有读操作——查询。大部分业务场景里，读请求的数量是写请求的五到十倍，这个分工天然合理。

常见部署形态叫"一主多从"：一台主库拖三到五台从库，主库出问题，从库随时顶上。主从之间通过一种叫 binlog 的日志文件保持同步——主库每次写数据，都会把操作记录写进 binlog，从库的 I/O 线程持续监听主库，有新日志就拉过来执行。

主库（写）
  ↓写binlog
从库1（读）← 中继日志执行
从库2（读）← 中继日志执行
从库3（读）← 中继日志执行

这个过程由两条线程协作完成：I/O 线程负责从主库拉数据，写进从库的"中继日志"；SQL 线程负责读中继日志、执行操作，让从库数据和主库保持一致。两条线程各司其职，主从同步才能顺畅运转。

考试常考一个知识点：主从复制有三种同步模式，分别对应不同的数据安全级别和性能代价。

异步复制是默认模式，主库写完 binlog 直接返回客户端，不等从库确认。性能最好，但主库挂了之后，最后几秒的写入可能丢。

半同步复制是折中方案，主库等待至少一个从库确认收到日志，才提交事务。性能略微下降，但至少保证"数据已经复制到某个地方"。小红书在2025年搞的 MySQL 内核优化，一个核心方向就是提升半同步复制的性能，让"日志传输加速"这件事做到极致。

全同步复制最保守，主库必须等所有从库都确认才返回。数据绝对安全，但性能损失太大，实际生产环境很少用。

选哪种模式，本质上是在"数据安全"和"系统性能"之间称量。业务能接受少量数据丢失、追求高并发，用异步；金融类业务一分钱都不能丢，用全同步；大多数互联网业务，半同步是合理的默认选择。

说回文章开头那个双十一的故事。主从数据库能解决四类问题：

读写分离：十台服务器同时写，全部打到主库；一百台服务器同时读，分散到五台从库。CPU 和内存的负载曲线瞬间从"一条陡峭的山峰"变成"五条平缓的丘陵"。

负载均衡：读请求打散到多个从库，单库连接数骤降，查询延迟从几百毫秒回到几十毫秒。想象一个餐厅把所有菜品都让一个厨师做，出餐要三十分钟；分成五个厨师同时炒，速度自然快五倍。

数据备份：从库实时同步主库数据，等于随时有一到多个热备份。主库硬盘坏了，从库直接顶上，RPO（恢复点目标）可以是零。小红书在2025年的实践中，靠自研 Binlog Server 把核心业务的 RPO 从60秒压到了0秒——故障切换时，数据真正实现了一秒不丢。

故障恢复：主库挂了怎么办？把其中一个从库"升职"成主库，切换流量，业务继续跑。整个过程从几小时人工操作，变成几十秒自动完成。

主从数据库不是银弹，它带来了两个必须正视的问题：

主从延迟：数据从主库写到从库，有时间差。这个差距叫 lag，可能是几毫秒，也可能是几秒甚至几分钟。如果业务逻辑要求"刚写入的数据立刻能读到"（比如支付后查余额），主从延迟就会让用户看到错误结果。

架构复杂度上升：多台数据库意味着要管复制关系、要监控延迟、要处理主从切换故障。以前一台数据库的事，现在变成了一个小型分布式系统的运维工作。

第一个问题有解：半同步复制可以显著降低延迟，或者在业务层做"写后读主库"的强制路由。第二个问题是代价——你想要高可用和高性能，就得付出运维复杂度。

主从数据库是互联网时代最经典的数据库架构之一，它的生命力来自于一个简单的事实：大多数业务的主要矛盾是"读多写少"，而主从分离精准地解决了这个矛盾。

如果你现在还只用一台数据库扛业务，不妨问自己一个问题：大促来的时候，你的系统会死在哪个环节？ 如果答案是数据库，十有八九是缺了主从分离这一层架构。

当然，主从不是终点。云原生时代，存算分离、Serverless 化的数据库正在吃掉传统主从架构的市场份额。但理解主从，是理解现代数据库架构的起点——就像理解瀑布模型是理解软件工程演化史的起点一样。

下一个问题是：你的系统，现在需要几台从库？