读写分离到底是大招还是人云亦云 ？真正做过的人有多少？

[huadi]

大部分所谓架构文章都会先介绍分库分表，再扛不住就读写分离对吧。

但没人往下讲细节了。
如果是异步同步，可以保证写主库成功之后返回，但保证不了延迟。比如写完马上读就会有问题。
如果等待同步从库成功后再返回，实际就是双写。那么故障几率就更大了，可用性就会降低。

好吧我知道还有所谓“具体业务具体分析”，但实际上哪有那么多具体业务能忍受可用性降低或者同步延迟。就比如订单，钱不能算错，库存也不能错，但没听说过谁说用可用性来做 trade off 的。

我始终认为，提升系统容量，要有一套能撑得住的运维体系，然后一直分库分表就好了。所谓主从同步，是一个“高可用”方案，在主库挂掉的时候从库顶上。而不是 scale out 方案。

那，真正做过读写分离方案的，到底有多少？

[bringyou]

@phx13ye 之前我司是这样。如果不局限于数据库的话，可以试试一些 newsql 或者 elasticsearch 这样的搜索引擎

[akira]

之前做读写分离，是把一些报表类的，不太要求实时性的查询 放在只读库 ，
大部分业务还是落在主库上面

[curdoldman]

SQL HINT 了解一下。
HINT 是一种可选的 SQL 片段或注释，可用于在 SQL 语句里强制索引，强制使用主库，强制不使用缓存等等

[fox0001]

我们是采用 Solr + 数据库，不完全的读写分离。但是 Solr 抗住了绝大部分的复杂查询，效果不错