[分布式] 想请教一些数据库复制(主从复制,读写分离)的问题

2018-09-07 23:28:51 +08:00
 monsoon

我想请教一些和数据库复制(主从复制,读写分离)相关的几个问题,不太懂这方面的东西,所以想请教下大家。(下面术语有些可能用的不对的话,楼下回帖直接开喷好了,我不太懂数据库 scale 这方面的东西……)

我有个主从复制,读写分离的集群(假设,实际上我现在还没有……)

  1. 正常设计的时候,所有的后端服务器都对主写的数据库进行访问,然后随便从任意一台从服务器访问读取?如果是任意一台的话会不会太随意了,还是说就是事先定好哪台服务器长连接哪台从的数据库就可以了?
  2. 如果从从服务器读的数据正好不是最新的那该怎么办(比如说你刚写了一个数据到主数据库,然后从从数据库读取那条数据的时候?我知道有一些模式可以解决这个问题,比如说最终一致性这类的,但是正常人是怎么解决这个问题的?
  3. 如果第二点读不到最新的写的数据,那么这个方案是不是根本就不 cp ( cap 理论里的 cp )了,还是说我理解错了 c ?

先谢谢解答的各位了。

1922 次点击
所在节点    程序员
3 条回复
msg7086
2018-09-07 23:57:56 +08:00
主从复制是会有延迟的,牺牲的数据及时性,换取扩展性。很可能你再次读取时读到的是 0.1 秒前的数据。
长连接随便你吧,随机读也是可以的,本来就很随意。
Raymon111111
2018-09-08 00:49:39 +08:00
1. 一般是任意一台, 看策略. 从库的目的本来就是分散请求压力
2. 主从同步问题肯定存在, 解决方案很多(比如延迟一段时间读 /直接读主库 /读不到从再读主 /别的更复杂手段获得需要数据), 主要看需求.
3. 至少从 mysql 集群正常使用的角度讲, 和 c 是搭不上边的.
wqlin
2018-09-08 09:50:10 +08:00
主从复制是为了提高可用性()和性能(读请求可以走从库,主库压力不会太大)。一般有好几种方式,以向数据库写数据为例:
1. 可以只等主库确认,那么就可以认为这次请求成功了;然后后续由主库将数据复制给其他从库( push 方式,也可以 pull )
2. 可以等主库将数据复制给全部从库,这样可以保证主从数据始终一致,不过这样性能不太高
3. 可以等主库将数据复制给部分从库,这样是上述两个方案的折中。
我们平时使用 mysql 主从复制的话,一般是第一种,不过 mysql 也支持第三种。那么就可能出现从库数据不一致。如果楼主应用能忍受这样的不一致,那么读从库就无所谓。如果要想读到最新的数据,可以将读请求路由到主库也是一种办法。不过这样主库读写压力会比较大。
不过还可以选择天生分布式数据库,国产 Tidb 这类

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/487269

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX