阅读笔记

DDIA-数据复制

2020-11-14  本文已影响0人  构建者

综述

首先介绍什么是复制,然后介绍了下主流的复制方式(主从),重点关注了主从复制的流程、技术实现及存在的问题。最后顺带介绍下另外两种复制方式基本理念,多主节点复制和无主节点复制。

为什么要复制

单台机器存储系统的容量是有限的,且无任何容错性。随着数据量越来越大,单台机器存储的系统越来越捉襟见肘,必然要进行扩展。分布式数据系统就是单机存储水平扩展自然而来,单机存储是简单的,分布式存储的复杂的,但对于因为分布式引入的复杂性,其提供的高可用、低延时、高吞吐更具备魅力及应用市场。
复制主要指通过互联网络在多台机器上保存相同数据的副本。通过复制我们可以达到以下三个目的:

  1. 低延时:使数据在地理位置上更接近用户,从而降低访问延时。
  2. 高可用:即使部分组件出现故障,系统依然可以正常工作。
  3. 高吞吐:扩展多台机器可以同时提供数据访问,从而提供读吞吐。

主从复制

这里假设数据规模相对还比较小,每个副本可以保持完整的数据集。

主从工作原理

  1. 指定某一个副本为主副本(主节点)。当可以写入数据时,必须将写请求发送给主副本,主副本首先将数据写入本地存储。
  2. 其他副本成为从副本。当主副本把新数据写入本地存储完成后,把新数据通过复制的形式发送给从副本,从副本根据复制数据进行本地存储,且严格保持与主副本相同的顺序。
  3. 客户端从数据库查询时,可以通过主从副本执行查询。

这么说,在客户端看了 ,主节点负责写入,而从副本是只读的不可写入的。

复制方式

  1. 同步复制
    主节点将数据同步复制给从副本,会等待所有副本确定收到后才算完成数据存储,即对于客户端来讲,要等待两个过程,第一主副本写入本地存储,第二从副本确认数据同步完成。
  2. 异步复制
    主节点将数据复制给从副本,无需等待确认。看起来是个不靠谱的选择,但实际异步复制应用场景更广泛。他也引入了问题:“复制滞后”。

节点失效

  1. 从节点失效情况,通过追赶式恢复从节点数据。
  2. 主节点失效情况,通过节点切换保障可用。选择一个从节点晋升为主节点;把新主节点告知客户端和其他从节点。这里会有个问题,即俗称的“脑裂”,切换不可靠时,会有两个主节点存在。

复制日志的实现方式

  1. 基于行的逻辑日志(推荐)
  2. 基于预写日志(WAL:write ahead log)
  3. 基于SQL语句
  4. 基于触发器

基于行的逻辑日志

基于WAL是存储和复制紧密耦合,严重依赖存储引擎。而基于行的复制通过逻辑日志,将复制和存储逻辑剥离。如:MySQL的binlog可以配置为该方式。

逻辑日志:关系型数据库的逻辑日志,指已系列记录来描述数据表行级别的写请求。

复制滞后问题

异步复制带来了“复制滞后”,即主从节点数据同一时间可能不一致。有问题就会有对应的解决方式。

  1. read-after-write
    该方式,优先保障当前用户能看到自己的最新数据,而其他用户不做保障。成为“写后读写一致性”,也成为读写一致性。可行方案有一下几种:
  1. 单调读
    对于同一用户,读取不同节点时,数据不一致问题的方案。比如:用户ID的hash将用户读取固定到一个副本。
  2. 前缀一致读
    对于数据先后顺序问题,比如两个对话,是有因果关系的。

那么复制滞后的解决方案是什么?是根据不同的一致性,做出不同抉择的权衡。

多主节点复制

对于主从模型的自然扩展,为了提高主节点的可靠性和吞吐量,可以配置多个主节点。但也因此因为了更为复杂的问题。比如:数据冲突,同时也需要根据冲突提供解决方案,避免冲突或者事后处理冲突等。

无主节点复制

主从复制和多主节点复制的核心思想,是客户端向某一节点写,然后数据库系统负责将数据复制给其他副本。
而无主节点复制采用了不同的设计思路:选择方式主节点,允许任何副本直接接受客户端的写请求。客户端直接将写请求发送给多个副本,副本确认数据存储。引入了读写quorun的概念,w+r > n,w指写入的副本,r值读取的副本数,n指节点数据。保证读写必须有重叠,即可通过版本来获取最新的数据。

上一篇下一篇

猜你喜欢

热点阅读