分布式复制系统设计-总结

复制或多副本技术的目的：

• 高可用 即使某台机器（或多台机器，或整个IDC）故障，系统也能保持正常运行
• 连接断开与容错 允许应用程序在网络中断时继续工作
• 低延迟 将数据放置在距离用户较近地，以更快交互
• 可扩展性 采用多副本，大幅提高系统的读吞吐量

多台机器保留多份相同的数据副本，需仔细考虑并发和所有可能出错并处理。至少，需处理好：

• 节点不可用
• 网络中断

这里甚至不考虑更隐蔽的失效场景，如由于bug导致的无提示的数据损坏。

多副本方案：

• 主从复制 所有客户端将写都发到单主节点，该节点将数据更改事件发送到其他副本（从节点）。每个副本都能接收读请求，但内容可能过期
• 多主复制 客户端发送每个写入到几个领导节点之一，任一都能接受写。领导者将数据更改事件流发送给彼此及所有跟随者节点
• 无主复制 客户端发送每个写到几个节点，并从多个节点并行读取，以检测和纠正具有陈旧数据的节点

每种方法都有优、缺点。单主复制很流行，因为易理解，无需担心冲突。出现故障节点，网络中断和延迟峰值时，多领导者、无领导者复制更稳健，但以更难推理并仅提供非常弱的一致性保证为代价。

复制可同步、异步，这在故障时对系统有深远影响。尽管系统平稳时异步复制很快，但复制滞后增加和服务器故障时要弄清楚会发生啥。若某领导者失败，且你提升了一个异步更新的追随者成为新的领导者，则最近提交的数据可能丢失。

一些可能由复制滞后引起的奇怪效应，也讨论了一些有助于决定应用程序在复制滞后时的行为的一致性模型：

• 写后读 用户应总看到自己提交的数据。
• 单调读 用户在某时间点看到数据后，不该在某更早时间点看到数据。
• 一致前缀读 用户应将数据视为具有因果意义的状态：如按正确顺序查看问题及其答复。

最后讨论多领导者、无领导者复制固有并发问题：因为他们允许多个写并发，这可能冲突。我们研究了一个DB可能使用的算法来确定：

• 一个操作是否发生在另一个操作之前
• 或它们是否同时发生

通过合并并发更新来解决冲突。