《设计数据密集型应用》第五章(3) 数据副本：Multiple-leader

上一节我们介绍了关于数据副本中的Single leader模型，该模型的一大缺点就是只有一个leader，如果leader出现故障，将无法向数据库中写入数据。

本节我们将介绍Multiple leader的复制模型，也就是有多个leader接收写请求，并将请求转发给其他follower，以及未直接接收到该请求的leader。

使用场景

对于单数据中心来说，使用多个leader的模型，增加的复杂性要比得到的收益更大。那么，Multiple-leader的使用场景主要有哪些呢？

多数据中心操作

对于多数据中心来说，如果使用Single-leader的话，leader只能在某个数据中心，所有数据中心的写请求都需要发送到该leader上。而使用Multiple-leader是很合适的，配置方式是为每个数据中心配置一个leader，每个leader将数据更新发送给其他的leader，数据中心内部使用常规的leader-follower的复制方式。

多数据中心的Multiple-leader

比较一下多数据中心的Single-leader和Multiple-leader两种方式：

• 性能：Multiple-leader允许写请求发送到离用户最近的数据中心，减少了数据传输的延迟，可以得到更好的性能。
• 数据中心故障容忍度：Single-leader在数据中心出现故障时，由其他数据中心的follower升级为leader；Multiple-leader可以直接将请求发送到其他数据中心，故障的数据中心在恢复前可以追上最新的进度。
• 网络故障容忍度：Multiple-leader对网络故障的容忍度更高，可以在临时的网络故障下继续工作。

Multiple-leader的最大缺点是当数据被多个数据中心修改时，可能出现数据的冲突，在后面会讨论这个问题。由于Multiple-leader的特性在和数据库的其他特性一起使用时存在一些不可预知的问题，比如自增key、触发器等，Multiple-leader的使用是比较危险，并且是要尽量避免的。

客户端离线操作

如果客户端希望在不连接网络时进行数据操作，使用Multiple-leader是合适的。比如用户的移动设备可能未连接网络，此时可以认为设备中的本地数据库是一个数据中心，可以先修改本地数据库，然后在连接网络后将修改同步到远程数据库。

这更像是一个多数据中心的问题，每个设备是一个数据中心，并且数据中心的网络连接是不可靠的。使用Multiple-leader能解决该问题，但仍然会存在一些数据复制的错误，需要一些tricky的手段。

合作编辑

一些在线编辑软件，允许多用户同时编辑一个文档。此时想象成用户修改本地的数据块，并将修改的数据异步复制到其他服务器，同样需要处理的是冲突的问题。

处理写冲突

Multiple-leader的最大问题就是可能会出现写冲突，因此需要解决写冲突的问题。

两个leader的写冲突

同步/异步冲突检测

如果采用异步冲突检测的机制，多用户都可以成功修改各自的数据，在随后的某个点进行冲突检测，此时可能已经来不及提示用户解决冲突了。

如果采用同步冲突检测的机制，只有数据replica复制完成后，其他用户才能写入数据，这样就丢失了Multiple-leader的好处，还不如使用Single-leader了。

避免冲突

解决冲突最简单的方法是避免冲突。比如用户只能修改他自己的数据时，可以将每个用户的写请求使用路由至相同的数据中心，从该用户的视角来看，这是一个Single-leader的模型。

但是当某个数据中心出现故障时，该方法就失效了，仍然需要处理不同数据中心可能的数据差异。

转换到一致的状态

如果能够将不同数据中心的数据副本的修改，最终统一为一致的状态，那么就不存在数据冲突的问题了。实现的方式有以下几种：

• 为每个写请求分配一个ID，选择最高的ID作为winner，并且丢弃其他的写请求。如果使用的时间戳，这项技术成为last write wins（LWW）。这项技术是很流行的，但可能会导致数据丢失，后面会继续讨论。
• 为每个数据replica分配一个ID，允许更高ID的replica覆盖低ID的replica。这种方法同样有可能会导致数据丢失。
• 将所有值合并在一起，比如按字母排序并串联起来。
• 在外部记录所有数据冲突，并由用户开发的应用代码在随后解决这些冲突。

自定义冲突解决逻辑

最合适的方法是由应用自定义冲突解决的方式，解决的时机有以下两种：

• 写入时：在写入时检测到冲突后，调用冲突处理器，执行写好的脚本解决冲突。
• 读取时：冲突发生时存储所有的值，在读取时检测到冲突，应用解决该冲突并将正确的数据写回到数据库中，CouchDB使用的是该方式。

需要注意，这种冲突解决的方法没有考虑一个事务中包含多个请求时事务的完整性。

Multiple-leader的拓扑结构

在Multiple-leader的模型下，leader之间的拓扑结构有以下三种形式：

Multiple-leader的三种拓扑结构

• 圆形/星型拓扑：写请求在leader之间按一定顺序转发。为了避免无限循环，为每个写请求打一个标记，标记已经处理过的leader，leader会丢弃已经处理过的请求。当某个node出现故障时，系统将无法通信，只能等待节点恢复。

• 多对多拓扑：写请求由一个leader同时发送给其他所有leader。该拓扑结构可以避免单一节点的故障导致的问题，但由于节点之前的传输速度不同，可能导致数据的顺序错误。

多对多拓扑，数据顺序错误

这类似一种因果关系的保证，因此可以使用类似时间戳的方式保证执行的先后顺序，但在多leader的情况下时钟时间是不能被信任的。后面我们会介绍一种称为version vertors的技术是用来解决该问题的。

小结

Multiple-leader的数据冲突问题，目前仍然很难被完美的解决，因此在确定使用该模型时，需要仔细阅读文档，并进行充分的测试，以保证提供了我们需要的可靠性。