分布式系统下如何进行数据复制？(上)

在开始讨论数据复制之前，我们需要一个理由为什么要进行数据复制？数据复制显然会给应用带来更高的复杂性，那么我们给出最大理由就是数据复制可以备份数据，使得节点挂掉的时候，保证数据不被丢失，应用还可以使用，而不仅仅因为这个，数据复制还会给我们带来一个更好读性能的提升，因为请求可以分发到不同节点，读取数据，而不是局限在一个节点，除了这两个，还有一个比较隐性的选择，如果是多地的复制，还可以减少对使用者的延迟。所以我们选择了数据复制，在下面的讨论当中，我们有一个前提，不考虑数据分区，而是假设数据集足够少。

对于数据间的复制，最流行的算法有三种：single-leader，multi-leader和leaderless。从三个算法的命名中，我们可以看出其中都牵扯到leader和follower的概念。那我们就从这两个概念开始吧。

什么是leader呢？别名有很多，例如master/primary。它负责接收client发出的request，如果是write的话，会先写入leader本身的storage，如果是read的话，则会分发给follower。那么follower呢？别名readreplicas, slaves, secondaries, hot standbys。它负责接收leader的log，然后更新自身的复制数据，也会返回leader发过来的read request需要的reponse。

这时我们注意到，leader和follower的数据交互，可以有两种选择，一个是同步，一个是异步。同步的意义是指当leader发送request给follower时，会一直等待所有follower回复了ok，才会确认这次请求是成功的，异步则相反，leader发送消息后，会立马确认成功，不会等待follower回复ok。如果稍微深入的话，我们可以发现选择同步的话，我们可以很好的保证数据的一致，但是随之而来的则是放弃了性能，而异步则无法保证leader发出的消息，follower是否真的接受到了吗？于是trade-off又出来了，一种特殊的半同步方式，follower发送消息，只会等待其中一个follower确认成功了，就会确认ok。

当然，leader和follower不可能时一成不变的，leader只有当其挂了之后，才会考虑设立新的leader。所以设立新的followe反倒是比较常见的情况，不考虑细节抽象的来看的话，首先确定leader在某个时刻的snapshot，再将这snapshot复制到新的follower，新的follower会连接leader获得最新的数据变化，最后这时follower就可以使用了，不过会在后台处理之前的snapshot。

作为一个分布式系统，最重要的一点就是如何处理Node Outages。在single-leader的情况下，follower如果失去了联系，很简单，只要等待恢复就好，反正有log的存在。那么最核心的问题就是leader宕机了，这个就是failover了。那么碰上这种情况，就要先确定leader是不是真的挂了，然后选择新的leader，可以使用专门的controller node处理，最后再重新注册新的leader。说起来容易，做起来实则非常难。有这么几个问题需要解决，1.如果是异步复制，新的leader和旧的leader中间的gap遗漏的数据怎么处理？2.旧的leader如果又活过来，follower该听谁的？(split brain)。3.如何确定合适的timeout去确定leader挂了。

最后再来看看该如何执行日志的复制。一般而言有下面几种方法：

1. statement-based复制

基于database的insert，update和delete语句去处理数据。这个方法听起来很靠谱，然而会有一些情况无法处理，比如statement使用了nondeterministic函数（NOW这些取决于当时情况的语句）、自增函数或者取决于当时存在数据的函数，甚至副作用也会存在。

2. Write-ahead log Shipping

对于基于log的database，可以直接选择复制log给follower。不过这个最大的影响是没有考虑到follower中间的版本不一致的问题，如果follower间有些先进行升级了，有些还是老的版本，那么对于log的解析就会出现不同的情况。

3. Logical(row-based)log replication

这个是log的基础上再做进一步处理，使其变得和要处理的数据一模一样。