分布式系统之 数据复制

复制的主要好处有：

1. 增强数据的可用性和安全性，复制实现了数据的备份。
2. 减少往返时间，复制技术可以把数据存储到各个数据中心，可以将用户的请求定向到最近的用户中心。
3. 增加吞吐量，一台服务器能够处理的请求存在物理上限，通过复制可以提供更多处理读写请求的机器，系统的处理性能能够成倍增长。

单主复制

单主复制也叫做主从复制或主从同步，指定系统中的一个副本为主节点，客户端的写请求必须发送到主节点，其余的副本称为从节点，从节点只能处理读请求，并从主节点同步最新的数据。

主节点收到写请求时，除了将数据写入本地存储之外，还要负责将这次数据变更同步到所有从节点，以确保所有的副本数据保持一致。

数据变更同步具体是同步操作日志还是转发请求，不同的系统有着不同的实现。

根据系统以何种方式同步数据，又可将单主复制分为三类：同步复制，半同步复制，异步复制。

• 同步复制

  
  同步复制.png

  同步复制保证了所有的节点都写入完成后才返回给客户端，后续无论哪个客户端从哪个副本读，都能读到刚才写入的数据。
  但是，因为主节点必须等待直到所有的副本写入完成，写请求性能必然会受到影响。

• 异步复制

  异步复制.png

  异步复制不会影响写请求的性能，但是异步复制会潜在影响副本数据的一致性和持久性。
  如果客户端收到写请求完成的响应后，立即去从某个节点读取数据，而此时写入操作还未同步到该副本，那么客户端会发现自己读不到刚才写入的数据。
  同时，如果主节点在本地写入完成后，立即宕机，那么写操作可能并没有同步到从节点上，如果此时强行将从节点升为主节点，那么新的主节点上的数据并不完整。

• 半同步复制

  
  半同步复制.png

  半同步复制是介于同步复制和异步复制之间的一种复制机制，主节点只需要等待至少一个从节点同步写操作完成并返回完成信息，不需要等待所有的节点完成。这意味着，至少一个节点是同步复制，其余的是异步复制，该同步复制的节点能随时接替主节点的工作。

总的说来单主复制，主要优点有：

• 简单易懂，易于实现。
• 仅在主节点执行并发写的操作，能够保证操作的顺序，避免了在各个节点处理数据冲突这类复杂的情况，这个特性使得单主复制更容易支持事务类操作。
• 对于大量读请求工作负载的系统，单主复制是可扩展的，可以通过增加多个从节点来提升读的性能。

主要缺点有：

• 对于大量写请求工作负载的系统很难进行扩展，因为系统只有一个主节点能支持写请求。
• 当主节点宕机时，从节点提升为主节点不是即时的，可能会造成一些停机时间。

单主复制是最常见，且最为广泛使用的一种复制方式。

多主复制

单主复制由于主节点只有1个，在写性能，可扩展性方面存在局限性。对于写请求负载要求严格的系统，一个自然的想法是增加多个主节点来分担写请求的负载，这种由多个节点充当主节点的数据复制方式就是多主复制。

多主复制.png

多主复制和单主复制的显著区别是：由于多主复制不止一个节点处理写请求，且网络存在延迟，这就意味着节点可能会对某些请求的正确顺序产生分歧。

冲突场景.png

其实数据冲突在单主复制中也会出现，只不过单主复制的数据冲突通常直接以主节点的数据作为最终数据。

为了解决这一问题，最先考虑的是有没有办法能够避免产生冲突：

• 特定的请求总是交给特定的主节点来处理，可以使用一个hash函数来路由，这样可以避免同一份数据在多个节点上更新。

如果冲突无法避免，那只有解决冲突了，按照系统特性，解决冲突的方法有：

• 由客户端解决冲突
  在客户端下入读取系统中冲突数据的时候，将冲突的数据全部返回给客户端，客户端选择合适的数据并返回给存储系统，存储系统以此作为最终确认的数据，覆盖所有冲突数据。

• 最后写入胜利
  最后写入胜利是让系统中的每个节点为每个写入请求标记上唯一时间戳或唯一自增ID，当冲突发生时，系统选择具有最新时间戳或最新ID版本的数据，并丢弃其他写入的数据。然而，在分布式系统中，是很难有一个统一的全局时钟的概念。

• 因果关系跟踪

总的说来多主复制，主要优点有：

• 增加主节点的容错性，一个主节点发生故障，另一个主节点仍然能够正常工作
• 可以在多个主节点上执行写请求，分担写负载的压力

主要缺点有：

• 增加了系统的复杂度，在多个节点上执行写操作，随着写节点数量增加，可能会产生更多的数据冲突

多主复制带来的复杂性远程它的好处，因此一般很少在单个数据中心使用多主复制，多主复制一般用于多个数据中心的存储系统。

无主复制

无主复制指的是完全没有主节点，尽管无主技术在几十年前就出现了，但直到亚马逊发布了 Dynamo 架构的论文，并在其中使用了无主复制，才让该技术重新引起广泛关注。

无主复制的基本思想是，客户端不仅向一个节点发送写请求，而是将请求发送多个节点，在某些情况下甚至会发送给所有节点。一旦得到其中一些节点的确认响应，就认为这次写成功了，然后继续发送下一个请求。

无主复制.png

但是，在无主复制下，一个绕不开的问题，数据冲突，写请求在节点1和节点3成功，但在节点2上失败了。

image.png

那么怎么在无主复制下解决数据冲突呢？

和写请求一样，客户端不止会从一个节点读取数据，读请求也会同时发送给多个节点，然后获取节点上的数据和数据版本号，客户端可以根据所有响应中的版本号决定应该使用哪个值，应该丢失哪个值。

虽然这种情况下，客户端可以识别出旧的数据，但我们仍然需要修复旧的数据，不能放任旧的数据一直在那。因此需要以某种方式将其与其他节点的数据保持一致，毕竟，复制技术的目的，是让多个节点存储相同的数据。

1. 读修复
   读修复就是让客户端从多个节点读取到数据后，可以检测到其中哪些节点数据是旧的，然后将最新的数据发送到这些旧数据所在的节点上，以此更新节点数据。

2. 反熵
   反熵过程会新建一个后台进程来修复数据，该进程找出错误的数据，并从存储最新的数据的节点中将数据复制到错误的节点。

• 基于 Quorum 数据冗余机制
  Quorum（法定人数）机制是分布式系统中用来保证数据冗余和最终一致性的一种算法。在前面提到，客户端要向一些节点发送读写请求，用于确定到底要多少个节点才足够，以及我们增加或者减少读写请求的节点数量，系统会发生怎样的变化。

  现在考虑，在一个3节点的系统中，假设客户端只需要写一个节点成功就认为此次写请求成功了，同样读请求也只需要从一个节点中读取。由于这些节点之间没有互相同步数据，因此客户端每次向唯一写成功的节点以外发送读请求时，都会读到过期的数据。
  显然，一个节点是不够的，我们需要增加读写请求的节点数量，来保证我们读到节点中至少有一个存储了最新写入的数据。现在，假设我们要求写至少2个节点成功，读至少从2个节点中读取数据，这样可以保证读取的两个返回值中至少有一个是最新写入的数据，因为三选二总会读到最新的数据节点，再然后我们可以根据时间戳或者数据版本判断出哪个是最新的数据。

  推广至更普遍的情况，基于的数据冗余机制保证了在一个由N个节点组成的系统中，我们要求至少W个节点写入成功，并且需要同时从R个节点中读取数据，只要 W+R > N，且 W > N/2，则读取的R个返回值中至少包含一个最新的值。

总的说来，无主复制优点有：

• 可以更轻松的容忍节点故障

缺点有：

• 数据冲突更多了，需要花更多的精力去处理数据冲突的问题

---

参考资料
1、《深入理解分布式系统》