大讲堂
先把“读写分离不是银弹”这事说透
很多人对读写分离的认知，还停留在十年前的老版本：把读流量扔给从库，主库只管闷头写，就能凭空把数据库性能翻个三五倍。 错了。 这套机制的本质，从来不是“免费的性能升级”，而是把单库内部本来互相抢资源的读、写操作，通过物理隔离拆成两个独立的资源池——主库扛所有带强一致性要求的事务性写入，从库扛所有对实时性要求没那么高的读取请求。主从同步延迟，就是这套方案天生带的天花板。
现在行业里的读写分离，早就不是老一套了
最早的读写分离是啥样？DBA手动改应用的连接串，写请求固定连主库，读请求固定连从库，一旦从库挂了，整个读链路直接崩。后来开源中间件出来了，ProxySQL、ShardingSphere这类工具自动做流量路由、自动做故障切换，算是把人工运维的负担降了一大截。 但现在头部玩家的玩法，早就跳出了“一主多从”的死板框架。热点数据的读请求，直接打到离用户最近的边缘缓存节点，根本不碰数据库；冷数据的读，扔到成本只有主库五分之一的归档存储层；甚至连“写”这个动作，都不是全堆在主库——非核心的日志类写入，直接走异步入队的旁路链路，根本不占主库的事务资源。
别光算性能账，这里的坑能埋掉创业公司半年利润
说实话，我见过太多团队一开始把读写分离想的太简单，觉得配两个从库就完事了，等真的出问题的时候，才发现原来之前算的账全错了。 第一个坑就是一致性成本。用户在支付页点了付款，写请求走主库落库成功，跳转到订单详情页的时候，读请求被路由到了还没同步完数据的从库，显示“订单不存在”——这种问题每1000个交易里出现1个，一年下来就是大几十万的客诉成本，更别提用户对平台的信任折损。 第二个坑是成本错配。很多创业公司刚拿到融资，上来就照着大厂的架构抄，配了一堆从库，结果实际业务的读流量根本没那么大，每个月光服务器成本就多花十几万，最后算下来，不如把钱投到产品功能上。 第三个坑是运维复杂度翻倍。原来单库的时候，出问题DBA登上去敲两行命令就能修好，现在搞了一整套读写分离集群，从同步链路到中间件路由，任何一个环节出问题，排查时间至少是原来的3倍。上次碰到一个客户，中间件的路由规则写错了，把写请求全路由到了只读的从库，直接报了10分钟的502，算下来损失的GMV够买3年的中间件授权费。 不过话说回来，也不能一棍子打死读写分离——如果你的业务是典型的读多写少场景，比如内容平台、电商商品详情页，那读写分离的投入产出比，比你换最贵的硬件数据库高10倍都不止。未来3-5年，读写分离会变成啥样？
第一个判断：固定比例的主从读写分离，会慢慢从主流方案里消失。现在云厂商的存算分离架构早就把主从绑定的逻辑拆掉了，写请求落到分布式存储层，读请求自动调度到离用户最近的计算节点，延迟、一致性全是平台自动调优的，你根本感知不到哪个是主哪个是从。 第二个判断：读写分离的逻辑边界，会从数据库层往整个应用栈延伸。现在的大模型推理不也在搞同样的事？用户的prompt输入是写，模型生成的高频内容缓存是读，把重复率高的prompt输出存在边缘节点，根本不用每次都让大模型重新算。本质上，这和数据库把读流量从主库拆出去的逻辑，没有任何区别。 第三个判断：中小团队会彻底告别手动搭读写分离的时代。以后不管是用云数据库还是开源分布式数据库，读写分离会变成开箱即用的默认能力，你不需要懂啥是binlog，啥是主从延迟，平台自动帮你把读流量调度到成本最低、延迟最低的节点。只有当你的业务规模真的到了百万级QPS的时候，才需要手动去调参数。 最后说句实在的。别听架构师吹啥“我们的读写分离架构扛得住双十一”，真到业务跑起来的时候你会发现，90%的公司根本不需要复杂的分布式方案——把最简单的读写分离规则跑稳，比啥花里胡哨的概念都管用。作者|fawen
排版|fawen
审核|知知