主从服务器对比主主复制，读写分离谁更稳

写请求全压在一台机器、读请求分出去，这套看着最土的做法，到今天还是大多数中小业务库的默认答案。主从服务器这套结构能活这么久，不是因为它先进，而是它出错的方式基本都在你预料之内——延迟高了、从库落后了、主库挂了要手动提一台上来，全是看得见摸得着的毛病。反过来，主主复制那种两边都能写的架构，出问题时往往是你没想到的那一种。

主从服务器的读写分离，稳在出错可预期

它的模型很单一：binlog 从主库单向流到从库，写入只走一个入口，读请求按权重分下去。从库上一定要把 read_only 打开，条件允许连 super_read_only 一起开，不然运维手一抖在从库上改了一条数据，主从就开始互相打架，等你去修的时候已经错了半天。

它不稳的地方也很明确，就是写这一侧是单点。主库整机挂掉，写入当场停住。能不能自动恢复，取决于你有没有上 MHA、Orchestrator 这类切换工具，或者干脆用 keepalived 把 VIP 漂过去。所以「稳」是有前提的：你得愿意为那一下切换提前做点准备，而不是等出事再翻文档。

主主复制看着灵活，冲突处理得自己扛

双主互相同步，两边都能写，听起来就比单写舒服。麻烦在于两台机器会同时生成主键——自增步进得设成 2，一台 offset 是 1、另一台是 2，不然两边生成的 ID 迟早撞上。唯一索引冲突更隐蔽，同一行数据两边同时改，后落地的那个把先落地的覆盖掉，业务上没有任何报错，只有用户跟你说数据不对。

真要上，通常得配合业务分片，让同一个用户、同一笔订单永远只往一边写，另一台纯粹当接管用。它适合的场景是异地双活、一边写挂了另一边立刻接上、对写入延迟特别敏感的那种。中小站点为了「高可用」三个字上主主，大概率是给自己找活干。

延迟这关，监控面板上的数字会骗人

Seconds_Behind_Master 这个值，在大事务、批量 DDL、从库回放吃力的时段经常报得过于乐观，显示 0 的时候其实已经落后了。想看得准一点，自己在主库建一张心跳表，每秒插一条带时间戳的记录，从库读出来减一下，这个差值才是真正的复制延迟。

业务侧更现实的做法是给读请求分级。注册完立刻跳个人中心、下单后马上查订单状态这类操作，必须强制走主库，或者给一个几秒钟的强制主库窗口。别指望用 sleep 顶过去，并发一上来这招立刻失效。

切换那一下，才是真正的考验

很多架构图上画得很漂亮，真到主库失联的时候才发现没人敢按那个按钮。切换之前要演练，切换之后要考虑旧主怎么办——它的 binlog 可能比新主还长，直接挂回去会把旧数据重新灌进来，通常的做法是用闪回工具处理掉那部分事务，或者干脆把旧主重建为从库。

还有连接池。应用里那些长连接、老连接还指着旧主的地址，VIP 漂过去了它们也不会自己改，得重启或者等连接超时。这种细节在文档里往往一笔带过，在现场就是半小时的业务中断。

程序层分流，还是一上来就上中间件

框架自带多数据源的做法最省事，注解标一下强制走主，事务里必须全走主库，代码量不大。中间件比如 ProxySQL 这类的好处是集中管理、改配置不用动代码，但它自己又变成一个新的单点，还得为它做高可用。

我的习惯是先让代码里分，把哪些必须走主、哪些可以容忍延迟列清楚，量真上来了再考虑中间件。顺序反了的话，你会花很多时间在调中间件的规则上，而不是在看业务到底需要什么。

落到你这摊业务，到底怎么定

写量不大、读多、有容灾要求，主从加读写分离就够了，成本低、坑也熟。两地都要能写、停一秒都难受，那才轮到主主或者双活，并且要接受冲突处理带来的复杂度。如果单库还撑得住，先别折腾复制架构，去把慢查询和索引看一遍。

最后提醒一句：复制架构只负责把读分出去，它分不掉一条烂 SQL 带来的锁等待，也救不了没有备份的误删。先把备份和一次真实的切换演练做完，再去纠结主从还是主主，顺序别搞反。