综述
首先介绍什么是复制，然后介绍了下主流的复制方式（主从），重点关注了主从复制的流程、技术实现及存在的问题。最后顺带介绍下另外两种复制方式基本理念，多主节点复制和无主节点复制。
为什么要复制
单台机器存储系统的容量是有限的，且无任何容错性。随着数据量越来越大，单台机器存储的系统越来越捉襟见肘，必然要进行扩展。分布式数据系统就是单机存储水平扩展自然而来，单机存储是简单的，分布式存储的复杂的，但对于因为分布式引入的复杂性，其提供的高可用、低延时、高吞吐更具备魅力及应用市场。
复制主要指通过互联网络在多台机器上保存相同数据的副本。通过复制我们可以达到以下三个目的：
- 低延时：使数据在地理位置上更接近用户，从而降低访问延时。
- 高可用：即使部分组件出现故障，系统依然可以正常工作。
- 高吞吐：扩展多台机器可以同时提供数据访问，从而提供读吞吐。
主从复制
这里假设数据规模相对还比较小，每个副本可以保持完整的数据集。
主从工作原理
- 指定某一个副本为主副本（主节点）。当可以写入数据时，必须将写请求发送给主副本，主副本首先将数据写入本地存储。
- 其他副本成为从副本。当主副本把新数据写入本地存储完成后，把新数据通过复制的形式发送给从副本，从副本根据复制数据进行本地存储，且严格保持与主副本相同的顺序。
- 客户端从数据库查询时，可以通过主从副本执行查询。
这么说，在客户端看了 ，主节点负责写入，而从副本是只读的不可写入的。
复制方式
- 同步复制
主节点将数据同步复制给从副本，会等待所有副本确定收到后才算完成数据存储，即对于客户端来讲，要等待两个过程，第一主副本写入本地存储，第二从副本确认数据同步完成。 - 异步复制
主节点将数据复制给从副本，无需等待确认。看起来是个不靠谱的选择，但实际异步复制应用场景更广泛。他也引入了问题：“复制滞后”。
节点失效
- 从节点失效情况，通过追赶式恢复从节点数据。
- 主节点失效情况，通过节点切换保障可用。选择一个从节点晋升为主节点；把新主节点告知客户端和其他从节点。这里会有个问题，即俗称的“脑裂”，切换不可靠时，会有两个主节点存在。
复制日志的实现方式
- 基于行的逻辑日志（推荐）
- 基于预写日志（WAL:write ahead log）
- 基于SQL语句
- 基于触发器
基于行的逻辑日志
基于WAL是存储和复制紧密耦合，严重依赖存储引擎。而基于行的复制通过逻辑日志，将复制和存储逻辑剥离。如：MySQL的binlog可以配置为该方式。
逻辑日志：关系型数据库的逻辑日志，指已系列记录来描述数据表行级别的写请求。
- 对于行插入，日志包含所有相关列的新值。
- 对于行删除，日志里有足够的信息来唯一标识已删除的行，通常是主键，但如果没有主键，就需要记录所有列的旧值。
- 对于行更新，日志包含有足够的信息来唯一标识更新的行，以及所有列的新值。
复制滞后问题
异步复制带来了“复制滞后”，即主从节点数据同一时间可能不一致。有问题就会有对应的解决方式。
- read-after-write
该方式，优先保障当前用户能看到自己的最新数据，而其他用户不做保障。成为“写后读写一致性”，也成为读写一致性。可行方案有一下几种：
- 访问修改的数据时从主节点读，否则读从节点。
- 根据更新时间，比如一分钟内更新从主节点读。
- 客户端请求中附带最近更新的时间戳，系统根据时间戳保障数据至少包含了该时间戳的更新。这个方案时钟同步是关键点。
- .....
- 单调读
对于同一用户，读取不同节点时，数据不一致问题的方案。比如：用户ID的hash将用户读取固定到一个副本。 - 前缀一致读
对于数据先后顺序问题，比如两个对话，是有因果关系的。
那么复制滞后的解决方案是什么？是根据不同的一致性，做出不同抉择的权衡。
多主节点复制
对于主从模型的自然扩展，为了提高主节点的可靠性和吞吐量，可以配置多个主节点。但也因此因为了更为复杂的问题。比如:数据冲突，同时也需要根据冲突提供解决方案，避免冲突或者事后处理冲突等。
无主节点复制
主从复制和多主节点复制的核心思想，是客户端向某一节点写，然后数据库系统负责将数据复制给其他副本。
而无主节点复制采用了不同的设计思路：选择方式主节点，允许任何副本直接接受客户端的写请求。客户端直接将写请求发送给多个副本，副本确认数据存储。引入了读写quorun的概念，w+r > n，w指写入的副本，r值读取的副本数，n指节点数据。保证读写必须有重叠，即可通过版本来获取最新的数据。
网友评论