这是一个创建于 2303 天前的主题，其中的信息可能已经有所发展或是发生改变。
我想请教一些和数据库复制（主从复制，读写分离）相关的几个问题，不太懂这方面的东西，所以想请教下大家。（下面术语有些可能用的不对的话，楼下回帖直接开喷好了，我不太懂数据库 scale 这方面的东西……)
我有个主从复制，读写分离的集群（假设，实际上我现在还没有……）
- 正常设计的时候，所有的后端服务器都对主写的数据库进行访问，然后随便从任意一台从服务器访问读取？如果是任意一台的话会不会太随意了，还是说就是事先定好哪台服务器长连接哪台从的数据库就可以了？
- 如果从从服务器读的数据正好不是最新的那该怎么办（比如说你刚写了一个数据到主数据库，然后从从数据库读取那条数据的时候？我知道有一些模式可以解决这个问题，比如说最终一致性这类的，但是正常人是怎么解决这个问题的?
- 如果第二点读不到最新的写的数据，那么这个方案是不是根本就不 cp （ cap 理论里的 cp ）了，还是说我理解错了 c ？
先谢谢解答的各位了。
 |
1
msg7086 2018-09-07 23:57:56 +08:00  1
主从复制是会有延迟的，牺牲的数据及时性，换取扩展性。很可能你再次读取时读到的是 0.1 秒前的数据。
长连接随便你吧，随机读也是可以的，本来就很随意。 |
 |
2
Raymon111111 2018-09-08 00:49:39 +08:00 1
1. 一般是任意一台, 看策略. 从库的目的本来就是分散请求压力
2. 主从同步问题肯定存在, 解决方案很多(比如延迟一段时间读 /直接读主库 /读不到从再读主 /别的更复杂手段获得需要数据), 主要看需求. 3. 至少从 mysql 集群正常使用的角度讲, 和 c 是搭不上边的. |
 |
3
wqlin 2018-09-08 09:50:10 +08:00 2
主从复制是为了提高可用性（）和性能（读请求可以走从库，主库压力不会太大）。一般有好几种方式，以向数据库写数据为例：
1. 可以只等主库确认，那么就可以认为这次请求成功了；然后后续由主库将数据复制给其他从库（ push 方式，也可以 pull ） 2. 可以等主库将数据复制给全部从库，这样可以保证主从数据始终一致，不过这样性能不太高 3. 可以等主库将数据复制给部分从库，这样是上述两个方案的折中。 我们平时使用 mysql 主从复制的话，一般是第一种，不过 mysql 也支持第三种。那么就可能出现从库数据不一致。如果楼主应用能忍受这样的不一致，那么读从库就无所谓。如果要想读到最新的数据，可以将读请求路由到主库也是一种办法。不过这样主库读写压力会比较大。 不过还可以选择天生分布式数据库，国产 Tidb 这类 |
Select Language