关于读写分离

• 資深大佬 : dog82

  如果并发不高，没必要读写分离吧，找到慢 sql 优化一下提升也很大

• 資深大佬 : guyeu

  1. 和并发有关系，提升效率最终目的是提升并发量；
  2. 架构选择和是否高并发没关系；
  3. 找到慢的原因，读写分离并不是解决慢的银弹；

• 資深大佬 : snappyone

  你先找到慢的原因再说吧

• 資深大佬 : namelosw

  1. 一般需要读写分离的系统如果不分离的话写的性能不符合要求，所以分离可以大幅提高写并发能力。
  2. 不一定，看怎么实现，比如纯 ES 没快照端压力稍大就要爆炸。
  3. 这个信息不够没法回答，而且可能也有别的解法。过不过度，主观题自行掌握。

• 資深大佬 : axyz233

  数据库读写分离还是 CQRS 职责分离？

• 資深大佬 : cheng6563

  读写分离不用做太多改造，是很容易实现的性能提升方式了

• 資深大佬 : opengps

  注意，读写分离是提高并发读，不是提高并发写，适合读写比例相差高的场景，比如 v2，一天接下来写入可能几千次，读出可能得几百万次，这时候读写比例很适合

• 資深大佬 : mtrec

  读写分离的场景是读多写少 是提高读的
  要提高写的话分库分表

• 資深大佬 : laminux29

  老一辈喜欢用读写分离，是因为：

  1.他们技术差。
  2.他们有提高性能的需求。
  3.他们用的软件，提高性能的最简单无脑的做法就是双机做读写分离。

  实际上读写分离是一种非常浪费资源的做法，但因为简单无脑，深受技术差的一帮人喜爱。

• 資深大佬 : hbolive

  @laminux29 还有个问题，是因为他们那个年代的机器差，跟现在差了几个量级，但是网民或者业务量却没差多少，所以折腾出这玩意儿。。

• 資深大佬 : namelosw

  @opengps 也是能提高并发写的，比如顶级的拍卖系统，最后一点时间狂写，每次开 Transaction 更新数据是来不及的，只能 append event 。读模型稍后跟上。

  读写分离的意义在于可以读写分开 Scale，这样就不容易被互相绊到。

• 資深大佬 : fihserman123

  读写分离的思想和技术栈新旧没有太大关系，Redis 算是新技术吧，也还不是推荐读写分离。写的开销比读大，所以不希望一个库既读又写，光写就吃不消了。读的需求又比写大，所以需要多个只读表。

• 資深大佬 : namelosw

  @hbolive 机器好也需要读写分离，因为读写分离提高的是 query 速度。Query 要是慢了什么复杂度都有，靠机器快是搞不定的。

  所以有的问题天生适合写的时候对 Query 进行 accumulate，而不是重新 query 。

• 資深大佬 : Jooooooooo

  读写分离主要是为了写的性能

  为了读的性能没必要分离, 多来几个从库搞定

  读写分离说的是主库不是必要不要去读, 机器资源都拿来写入

• 資深大佬 : kanepan19

  读写分离，为了避免读影响写， 也为了避免写影响读。

• 主 資深大佬 : zxc1234

  @Jooooooooo 读会影响到写？

• 主 資深大佬 : zxc1234

  @mtrec 那如果读多写少，但是并发不大，用读写分离会设计过度吗？

• 主 資深大佬 : zxc1234

  @laminux29 不用读写分离 用什么呢

• 資深大佬 : Jooooooooo

  @zxc1234 会. 挪走读对提升整个写的性能是有帮助的. 所以主库不是迫不得已就不要读.

• 主 資深大佬 : zxc1234

  @Jooooooooo 读怎么影响到写？

  另外，我一直觉得因为写有锁啥的会影响读的性能，所以才分离，我是理解错了吗

• 資深大佬 : Jooooooooo

  @zxc1234 读写都要消耗 mysql 机器资源的, 把读消耗的资源让出来给写用

• 資深大佬 : mtrec

  @zxc1234 具体问题具体分析 你先写个读写一体的试试不就知道了 架构的问题都不是一蹴而就的 慢慢演变过来就好