关于读写分离

[zxc1234]

想问下：

我的理解是读写分离是为了读，提升读的效率。

1.那么跟并发有关系吗？

2.用读写分离架构一定是高并发吗？

3.我司一个内部系统，内部人员在使用，但是希望读数据快点，用读写分离会设计过度吗？

谢谢~

[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 具体问题具体分析 你先写个读写一体的试试不就知道了 架构的问题都不是一蹴而就的 慢慢演变过来就好