数据复制模型有哪些

数据复制架构

主从复制、多主复制、无主复制

深入浅出分布式技术原理 Mapping

数据复制方案

  • 同步复制 —— mysql,主备复制 or 数据一致性要求较高场景,如金融
  • 异步复制 —— mysql,redis,响应延迟要求高,可用性优先
  • 半同步复制 —— mysql,raft、zoopkeeper
    • 一种是,当主数据库收到多个备数据库中的某一个回复数据同步成功后,便可给用户响应写操作完成;
    • 另一种是,主数据库等超过一半节点(包括主数据库)回复数据更新成功后,再给用户响应写操作成功。

各个数据存储的数据复制方案

  • MySQL:有同步复制、异步复制、半同步复制。MySQL 5.7 版本之后增加的一种复制方式,介于两者之间,事务线程不用等待所有的从库复制成功响应,只要一部分复制成功响应回来就行,比如一主二从的集群,只要数据成功复制到任意一个从库上,主库的事务线程就可以返回给客户端。
  • Kafka:ack=0,ack=1,ack=all

扩展问题

如何解决主从复制的延迟问题

案例分析

在电商平台,每次用户发布商品评论时,都会先调用评论审核,目的是对用户发布的商品评论进行如言论监控、图片鉴黄等操作。评论在更新完主库后,商品发布模块会异步调用审核模块,并把评论 ID 传递给审核模块,然后再由评论审核模块用评论 ID 查询从库中获取到完整的评论信息。此时如果主从数据库存在延迟,在从库中就会获取不到评论信息,整个流程就会出现异常。

架构上的解决方案

  • 使用数据冗余。异步调用审核模块时,不仅仅发送商品 ID,而是发送需要的所有评论信息,避免在从库中重新查询数据(简单易实现,推荐)。但要注意每次调用的参数大小,过大的消息会占用网络带宽和通信时间。
  • 使用缓存解决。把评论数据写到 Redis 缓存里,优先查询缓存,也可以保证数据的一致性。不过这种方式会带来缓存和数据库的一致性问题,比如两个线程同时更新数据。
  • 直接查询主库。需要谨慎,数据量不能太大,不然会出现主库写请求锁行,影响读请求的执行,最终对主库造成比较大的压力。

怎么实现主从库的数据访问

  • 方案一
    • 代码中配置读写操作访问的数据源,不同 SQL 访问不同数据源。
    • 优点:简单实现。
    • 缺点:路由规则入侵代码,不利于维护。
  • 方案二
    • 独立部署的代理中间件,如 MyCat,代理多个数据库。潜入到程序的,语言单一;独立部署的,增加维护。
    • 优点:隔离底层数据库与上层应用的访问复杂度
    • 缺点:跨两次网络传输,有性能损耗,增加了运维成本

为什么主从复制不能一直加机器?

因为主机需要维持更多连接,发送更多数据,占用带宽等。

主从复制会引入什么复杂性?

写数据写到多少机器中,ack all 还是 1。主从延迟问题——缓存、冗余字段、访问主库。

参考链接