数据库读写分离架构到底哪里让人不爽，聊聊我的真实感受和那些坑

主要参考自知乎专栏文章《用了三年读写分离，我为什么又回到了单库》，并结合部分技术社区如CSDN、开源中国上的开发者讨论）

说实话，刚接触读写分离那会儿，感觉就像捡到了宝，主库负责写，一堆从库负责读，听起来特别美好，感觉系统性能能瞬间起飞，高枕无忧了，但真用上几年，踩过一堆坑之后，我才发现，这玩意儿远没有宣传的那么省心,有时候甚至觉得是给自己挖了个大坑。

第一点最让我不爽的，就是数据延迟这个“幽灵”。 这是读写分离架构最经典、也最折磨人的问题，理论上，主库写完数据，从库很快就能同步过去，对吧？但现实是，“很快”是多快？毫秒级？秒级？有时候甚至是分钟级！这完全取决于你的网络状况、数据库负载和数据量，我记得特别清楚，有一次用户刚在后台完成了一个重要操作（比如支付成功），页面立刻跳转去查询结果，就因为查询请求被路由到了还没来得及同步的从库，显示的还是未支付状态，用户反复刷新，有时候能刷出来，有时候刷不出来，直接一个投诉电话就打到客服了，这种场景下，你根本没法跟业务方解释什么是“主从同步延迟”，他们只会觉得你的系统有Bug，为了解决这个问题，我们不得不搞出一些“骚操作”，比如针对某些关键查询强制走主库，但这又违背了读写分离减轻主库压力的初衷,让架构变得不伦不类。

第二坑是代码变得贼复杂，心里总得绷着一根弦。 本来简单的增删改查，现在你得时时刻刻想着：我这条SQL是读还是写？该走哪个数据源？虽然可以用中间件或者框架来做自动路由，但并不是所有查询都能被准确分类，一个事务里，先写后立刻读，这个读如果走到了从库，就可能读到旧数据，导致业务逻辑出错，这就逼着开发人员在写代码时要有很强的“一致性”意识，甚至要在业务逻辑里显式地指定数据源，时间一长，代码里到处都是这种“补丁”，维护起来特别头疼，新来的同事一不小心就会踩坑，我们还得花大量时间给他们普及“我们家的数据库使用规范”,心累。

第三，运维的复杂度是指数级上升。 以前就一个数据库，监控、备份、扩容都相对简单，搞了读写分离之后，你好几个从库，每个都得监控其同步状态（Seconds_Behind_Master这个值都快看成斗鸡眼了），主库挂了吗？那还好说，起码有高可用方案，但要是某个从库同步卡住了或者挂了呢？你得赶紧把它从读库集群里摘出来，然后排查问题、修复数据，确保它重新追上主库进度后再加回去，这个过程非常繁琐，而且对运维人员的要求高了很多，扩容也一样，加一个读库可不是简单启动个实例就行，你要考虑数据同步的起点、会不会影响线上业务等等,感觉团队一半的运维精力都花在伺候这几个数据库的关系上了。

第四，它并不是所有性能问题的万能解药。 我们当初上读写分离，很大程度上是因为有几个报表类的SQL太慢，拖累了主库，本以为把查询分摊到从库就万事大吉，结果发现，那些写得烂的、没加索引的复杂查询，放到从库上跑，一样慢！而且可能把从库也拖垮，读写分离主要解决的是“读”的并发压力，但对于单条慢查询的优化，它无能为力，真正的问题可能出在SQL本身或者表结构设计上，不从根本上解决，只是把问题从一个地方转移到了另一个地方,属于治标不治本。

成本问题也让人肉疼。 多一台从库，就多一份硬件（或云服务）成本，为了确保高可用，你可能还得做从库的高可用，成本又上去了，有时候静下心来算笔账，为了应对那偶尔出现的读高峰，养着这么多平时利用率不高的从库，到底值不值？也许当初把这些成本投入到优化数据库本身（如升级SSD硬盘）、优化SQL、或者引入缓存（如Redis）上,性价比会更高。

经历了这么多，我的真实感受是：读写分离是一个有用的架构模式，但它绝对不是一个可以无脑上的银弹，它引入了数据一致性、系统复杂度和运维成本等一系列新问题，现在我们的策略变得保守了很多：只有当确确实实遇到了巨大的读压力，并且通过其他优化手段（比如缓存）都无法有效解决时，才会非常谨慎地考虑引入读写分离，而且会事先做好充分的技术预案和业务评估，不然，一个设计良好的单库,可能比一个满是坑的读写分离集群要香得多。