【分布式系统遨游】分布式数据复制

今天咱们来讨论分布式数据复制。

为何须要数据复制

咱们在上一篇文章中谈到了分布式数据的分片存储技术，其核心在于将原数据划分为多个数据子集，而后将每一个子集分散到不一样的集群节点上存储，以实现负载均衡。那么，这里实际上是有一个问题的。因为每一个节点上面的数据彻底没有交集，假设其中一个节点挂了，那么这个节点上的数据就丢失了。因此，咱们须要一种技术方案，在数据分片的基础上，实现分布式集群的高可用性与可靠性，这就是咱们今天要讨论的分布式数据复制技术。

数据复制是什么

数据复制就是一种数据备份技术。好比如今有集群节点1，那么咱们会启用节点2，将节点1上的数据拷贝到节点2上，这样节点1与节点2上的数据彻底相同。当节点1挂了的时候，能够当即启用节点2，继续对外提供数据存取服务，实现了分布式存储系统的自动容错。

数据复制的几种方案

要想节点2可以彻底代替节点1进行工做，那么节点2必需要与节点1上的数据一致。可是这个一致性也要分强弱。咱们接下来回顾一下CAP理论。
P就是指在集群中网络出现故障的时候，集群内的网络就被隔离开了（分区），可是必须可以对外正常提供服务。因此，因为分布式系统中的网络故障不可避免，P是必须知足的，不然就退化成了单机系统。另外一方面，这条原则就让咱们必须将数据分散到多个物理节点上，才能在某一条网络链路出现故障的时候，让副本节点顶上来，对外继续正常提供服务，这也就是咱们为何要作数据冗余备份与数据复制。

可是CAP理论又告诉咱们，只能知足CP（偏一致性）或者AP（偏可用性）。那么，为何CAP不能同时知足呢？假设咱们就要知足CP，各节点间实现强一致性。那么，假设我对其中一个节点进行写操做，那么这个写操做就会一直阻塞等待，直到将更新后的数据同步到另外一个节点上才会返回写操做成功。返回以后，才能够进行后续的读请求。这样保证了不管读哪一个节点，数据都是一致的。可是，因为咱们在复制完成以前一直会阻塞，会致使写操做等待时间较长，这样就损失了一部分可用性。因此，CAP是不可能同时知足的。像支付这种场景可能会追求CP（一致性），而电商这种场景更追求AP（可用性）。
基于以上分析，就能够引出咱们三种不一样的数据复制方案：

• 同步复制技术，注重一致性；
• 异步复制技术，注重可用性；
• 半同步复制技术，介于前二者之间。

接下来咱们以数据库主从同步为例，逐一讨论。

同步复制技术

同步复制技术保证的是各节点之间的数据强一致性，因此，像咱们刚才说的那样，在数据库读写分离时，用户更新数据的请求会打到主数据库节点上。主数据库必需要同步到备数据库以后才可给用户返回，即若是主数据库尚未同步到备数据库，用户的更新操做会一直阻塞。这种方式保证了数据的强一致性，但牺牲了系统的可用性，即CP。

这种方案适用于对数据一致性有严格要求的场合，好比金融、交易之类的场景。

异步复制技术

异步复制技术主要保证可用性，各节点之间容忍暂时的数据不一致，保证最终一致性便可。因此当用户请求更新数据时，主数据库处理完请求后可直接给用户响应，而没必要等待备数据库完成同步，即备数据库会异步进行数据的同步，用户的更新操做不会由于备数据库未完成数据同步而致使阻塞。这种方式保证了系统的可用性，但牺牲了数据的一致性，即AP。

MySQL 集群默认的数据复制模式，采用的就是异步复制技术。咱们主要关注两个关键的组件：binlog与relay log。
既然是异步，那么咱们直接在主节点上执行完就能够返回了，让备数据库获取咱们的更新内容，本身去作同步就行了，不用那么着急。因此，咱们须要找个地方记下来作了什么操做，这里binlog就派上用场了。MySQL会往binlog中写入主数据库执行的全部更新操做，以便备数据库获取更新信息。而后备数据库专门启动一个IO线程读取binlog的内容，而后写入本身的relay log中。备数据库会有一个后台线程按期检查relay log的内容，一旦发现有更新，当即重放relay log，最终与主节点的数据达成一致：

这里我再额外提一下relay log，网上不少文章都没有说为何要使用relay log。因为relay log是在从节点那一侧，那么从节点就能够在relay log上记录当前同步的进度并作各类标记。就至关于把公共资源复制了一份据为己有，我就能够基于这份复制的东西随心所欲了。而若是没有relay log，直接去读取并重放binlog的话，就无法实现了。此外，读取binlog并直接重放bionlog这个过程，相比直接拷贝binlog的内容到relay log这种方案，多了一个重放这个步骤，这就要多占用不少主从节点之间网络链接的时间资源，致使性能降低。因此，这就是为何要使用relay log。
异步复制技术大多应用在对用户请求响应时延要求很高的场景。好比电商、秒杀这类场景。这时后台的数据库或缓存若是采用同步复制技术，用户可能就会因服务响应速度慢而崩溃，最终致使用户流失。所以这种场景最好采用异步复制技术，优先保证可用性。

半同步复制技术

半同步复制技术顾名思义，介于前两种方案之间。知足了一部分可用性及一致性。半同步复制技术主要应用在一主多从场景中。主节点不用等待全部备节点同步完毕就即可以响应写操做成功。也就是说，主节点能够等待一部分备节点同步完成后，就能够响应用户写操做执行成功。
而这里基于要等待多少个节点响应成功才算写操做成功，有细分为两种方案：

• 主节点收到一个备节点同步成功，就返回写操做成功；
• 主节点收到超过一半节点回复数据同步成功后，再给用户响应写操做成功。

这两种方案相对而言，第一种更偏向可用性，第二种更偏向一致性。在MySQL一主多备的场景下，通常采用的是第一种半同步复制技术。而Zookeeper则采用了第二种半同步复制技术。
实际上，多数的分布式存储系统与中间件，能够经过配置来选择不一样的数据复制技术。咱们根据咱们本身的业务场景，选择合适的数据复制方案便可。

下期预告

【分布式系统遨游】分布式缓存

关注咱们

欢迎对本系列文章感兴趣的读者订阅咱们的公众号，关注博主下次不迷路～