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

对于single-leader的数据复制模式，并且我们选择了异步的方式对数据进行处理。假如写入数据和读取数据都出现了并发的情况，显然数据会出现短时间不一致的情况，不过最后都会变成一致。但是这个短暂的时间差足以产生相当大的问题。主要可以分为三类：

1. Reading Your Own Writes

想象一下，我在朋友圈发了一条动态，服务器在后端接受了数据，然后leader将数据拷贝到对应的follower上，由于发生了些许的网络延迟，数据只是拷贝到了follower1上，但是此时你刷新了朋友圈，希望能看到刚刚发出的动态，于是手机向服务器请求希望获得刚刚发出的动态，leader没有向follower1请求数据，而是向follower2请求数据，follower2还没有来的及接受到之前的写数据，follower2回复没有最新的数据，此时你的朋友圈再刷新的时候就会发现我刚刚发的消息去哪了？这就是你读不到你写入的数据了。

那么我们该如何解决呢？

首先我们可以从leader缓存刚好的数据，直接从leader读，或者是client记住最新的时间戳，leader读取数据时确保读到的数据是最新的时间戳。

1. Monotonic Reads

这个情况类似于上述的例子，需要区别的是，我们在刷新朋友圈的时候，第一个请求恰巧发给了follower1，得到了刚好发出的动态，但是过了一会再刷新，请求给了follower2，这个是没有接收到最新的动态的，于是你崩溃了，怎么我再刷新一遍我刚好的数据就没有了呢？

这个的解决办法很简单，只要保证数据的请求每次都来源于同一个节点接好了。

1. Consistent Prefix Reads

这个来源于因果性，还是讲例子吧。现在有一个对话，问：你叫啥名？答：小明。这个对话正在写入数据库，假设此时有个听众，他向数据库发送请求，由于网络延迟，后一个答先写入了，于是听众看到的数据就变成了小明/你叫啥名，显然违反了因果性。

解决办法需要数据库保证任何相关的写都是同时写入同一个节点。

在分析完single-leader的情况下，我们来看看multi-leader。我们很容易想到single-leader对于leader的要求太高了，所有的写都必须经过它，自身的压力也足够大，所以自然而然的想到了multi-leader。在现实生活中multi-leader也有着极为广泛的应用，例如多地分布的数据中心，协同编辑等等。当然我们很容易推理出来，single-leader遇上的麻烦，multi-leader也会遇上，除此之外，multi-leader还需要解决写冲突的问题。

什么是写冲突呢？在multi-leader的情况下，写数据的请求会分发到不同的leader上，假设有两个leader，leader1和leader2，leader1接收了一条请求要将x改为B，同时leader2接收的信息是x改A，那么数据库的数据x到底是A还是B呢？当我们想要解决这个写冲突时，那就必须一个coordinater先确定冲突，那么又回到了single-leader了。

既然无法从根本上解决，那就要根据具体情况具体分析了。对于多地的数据中心，数据的请求可以不需要经过分发，而是同一个user的请求只会进入到对应于它的数据中心。虽然这个有所缓解，但是依然存在一个问题，user移动了位置，那么对应的数据中心也发生了改变，还是要面临着如何解决写入冲突的问题。一般而言，有四种方式：1.使用唯一的ID(timestamp, a random number)，选取数值最高的ID，这也就是著名的LWW，last writewins。2.给每一个副本一个唯一ID，选取最高ID的副本解决冲突3.将数据合并在一起，比如将前面的A，B变为A/B。4.直接将冲突的信息保存下来，稍后再解决，甚至直接抛给user去解决。上面四种方法也是要根据业务去选择如何解决写入冲突问题。

聊完multi-leader，最后看看leaderless。Leaderless replication最为出名的是亚马逊的Dynamo系统，这个系统影响了一大批leaderless的数据库，于是leaderless也被称为Dynamo-style。对于leaderless系统，可用性发挥到了极致，因为它的数学核心只有一个不等式，w+r>n。client在读取数据时，会首先确定之前写的时候写入了w个node，在读取的时候，就会读取r个node，只要保证w+r>n那么必然会有一个读取的数据是最新的数据。

从理论上来看，w+r>n，整个系统至少可以容忍n/2的node挂掉。显然我们获得了极高的可用性，但是一致性的我们就要失去了，我们需要时间去保证有w或r个node回复信息。写冲突和读冲突的问题也需要解决。