数据复制二(多主复制详解)

目录

一、多主复制

二、多主复制常用的场景

三、多主复制处理写冲突

四、自定义冲突解决

---

一、多主复制

在上一篇文章谈到了主从复制，对于一个超大规模应用，主从往往是不够用的。还需要多个数据中心，这些数据中心可能部署的全球的任何一个位置。每个数据中心都是主从配置，数据中心的主节点对于其他数据中心来说就是从节点。一个数据中心数据发生变化，异步同步到其他的数据中心的主节点。

为了容忍整个数据中心级别故障或者更接近用户,可以把数据库的副本横跨多个数据中心。而如果使用常规的基于主从的复制模型,主节点势必只能放在其中的某一个数据中心,而所有写请求都必须经过该数据中心。

下面是多个数据中心的多主节点复制模式，图是我在网上找的。

多数据中心的好处：

1. 我们可以根据用户的地理位置把数据存在离用户最近的那个数据中心快速响应，然后采用异步复制方式将变化同步到其他数据中心。因此，对上层应用有效屏蔽了数据中心之间网络延迟，终端用户更好的体验

2. 提高的系统的高可用性，用户的数据中心发生故障，可以直接切换到其他的数据中心。等到故障的数据中心在恢复之后更新到最新状态

有些数据库己内嵌支持了多主复制, 但有些则借助外部工具来实现, 例如MySQL的Tungst Replicator, PostgreSQL的BDR 以及Oracle 的GoldenGate。 优点很明显，缺点也很突出：不同的数据中心可能会同时修改相同的数据，因此必须解决潜在的写冲突。

二、多主复制常用的场景

1. 离线客户端操作：应用在网络断开后还要继续工作的场景。 我们常常用到的手机，笔记本电脑和其他设备上的日历应用程序。无论设备当前是否联网,者r s 需要能够随时查看当前的会议安排(对应于读请求)或者添加新的会议(对应于写请求)。在离线状态下进行的任何更改,会在下次设备上线时伞,与服务器以及其他设备同步。

   这种情况下,每个设备都有一个充当主节点的本地数据库(用来接受写请求),然后在所有设备之间采用异步方式同步这些多主节点上的副本,同步滞后可能是几小时或者数天,具体时间取决于设备何时可以再次联网。从架构层面来看,上述设置基本上等同于数据中心之间的多主复制,只不过是个极端情况,即一个设备就是数据中心,而且它们之间的网络连接非常不可靠。多个设备同步日历的例子表明,多主节点可以得到想要的结果,但中间过程依然有很多的未知数。有一些工具可以使多主配置更为容易,如Couch DB就是为这种操作模式而设计的。

2. 协作编辑：允许多个用户同时编辑文档。例如，石墨文档，这种业务和多主复制，有相似的地方，我们归位多主复制，当一个用户编辑文档时，所做的更改会立即应用到本地副本，然后异步复制到服务器以及编辑同一文档其他用户。

3. 还是就是我们上面所说的多主复制也可以叫多活

三、多主复制处理写冲突

对于冲突来说很多人想到冲突检测，这不是一个好的想法，先谈谈同步检测，就是数据中心的主节点写到所有的数据中心成功后，才认为是成功的,那对于多数据中心来说，就变成了主从模式，失去了多数据中心的优势l。异步检测是并不能很好的实现，多数据中心的数据同步是异步的，我们异步检测时，数据或许已经同步了，已经产生冲突了，具有滞后性。

如何避免冲突呢？

有人想到我们总是把数据路由到离用户更近的数据中心，访问时也从这个数据中心访问。其实大家也是这么做的，为啥还有数据冲突了。1、数据中心故障，数据中心发生切换 2、用户已经漫游到另一个位置,因而更靠近新数据中心。

上面的方法是不可以的，那么数据库必须以一种收敛趋同的方式来解决冲突，这也意味着当所有更改最终被复制、同步之后,所有副本的最终值是相同的。

实现收敛的冲突解决有以下可能的方式

1. 给每个写入分配唯一的ID,例如,一个时间戳,二个足够长的随机数,一个UUID 或者一个基于键值的哈希,挑选最高ID 的写入作为胜利者,并将其他写入丢弃。如果基于时间戳,这种技术被称为最后写入者获胜。虽然这种方陆很流行,但是很容易造成数据丢 失 [3 5] 。我们将在本章最后部分来详细解释。

2. 为每个副本分配一个唯一的ID ,井制定规则,例如序号高的副本写入始终优先于序号低的副本。这种方法也可能会导致数据丢失。

3. 以某种方式将这些值合并在一起。例如,按字母顺序排序,然后拼接在一起

4. 利用预定义好的格式来记录和保留冲突相关的所有信息,然后依靠应用层的逻辑,事后解决冲突(可能会提示用户)

根据不同业务不同的方式解决吧，提一句唯一的ID 应该是具有全局性，可以通过用户id 生成全局的自增的id，利用redis 就可以。也可以用全局的id

四、自定义冲突解决

解决冲突最合适的方式可能还是依靠应用层,所以大多数多主节点复制模型都有工具来让用户编写应用代码来解决冲突。可以在写入时或在读取时执行这些代码逻辑：

在写入时执行只要数据库系统在复制变更日志时检测到冲突,就会调用应用层的冲突处理程序 。例如,Bucardo 支持编写一段Perl 代码。这个处理程序通常不能在线提示用户,而只能在后台运行,这样速度更快 。

在读取时执行当检测到冲突时,所有冲突写入值都会暂时保存下来。下一次读取数据时,会将数据的多个版本读返回给应用层。应用层可能会提示用户或自动解决冲突,井将最后的结果返回到数据库。CouchDB 采用了这样的处理方式。

注 意 ,冲突解决通常用于单个行或文档,而不是整个事务 。因此,如果有一个原子事务包含多个不同写请求。每个写请求仍然是分开考虑来解决冲突 。

这是在数据传输到其他数据中心，由数据中心自己解决冲突

所谓冲突就是写操作同时修改同一个记录的同一个字段，并设置成不同的值，这就是冲突。