分布式数据库系统中主从、主主和无主三种复制算法

分布式系统中的复制对于确保数据一致性、可用性和系统弹性至关重要。这是一种将数据存储在多个节点或服务器上的策略，即使在服务器故障或维护期间也可以防止数据丢失并实现不间断访问。

1、单领导者主从复制：
涉及一台主服务器（领导者）处理所有写入操作，而多个辅助服务器（跟随者）复制这些更改。非常适合保持强一致性和数据完整性，广泛应用于写操作至关重要的场景。

2、多主复制：
每个节点都可以接受写操作，并且更改在节点之间同步。这种方法对于延迟和写入冲突解决是关键考虑因素的分布式系统是有益的。

3、无领导复制：
所有节点都可以接受读取和写入，通常用于高度分布式架构中，以增强可用性和分区容错性。

什么是复制？
复制分同步复制和异步复制：

• 在同步复制中，当用户更新其配置文件时，更新将发送到领导服务器。领导者立即更新其本地存储，同时将此更改传播到跟随者服务器。只有在成功更新自己的存储和追随者之后，领导者才会向客户端发送成功消息。此方法始终确保所有节点之间的数据一致性，但由于需要立即传播到追随者，因此可能具有较高的延迟。
• 异步复制：涉及用户向领导者发送配置文件更新，然后领导者更新其本地存储。与同步复制不同，领导者不会立即将此更新发送给追随者。相反，它会在延迟后传播这些更改，这可能基于设定的时间表或由某些条件触发。更新关注者后，领导者会向客户端发送成功消息。此方法可以为客户端的初始请求提供较低的延迟，因为它不等待关注者更新。然而，这可能会导致领导者和追随者之间暂时的不一致。

（1）单领导者复制
将新追随者无缝集成到复制系统中
在数据流连续的动态环境中，向复制系统添加新的追随者可能具有挑战性。直接将数据从一个追随者复制到另一个追随者通常效率低下，并且可能导致不一致，尤其是在实时写入时。

例如，想象一下复制正在进行的事务的数据库。当复制完成时，大量新事务将被添加到原始数据库中，从而使复制的版本过时且不完整。
锁定数据库以防止在复制过程中进行写入是另一种方法，但这与高可用性原则相矛盾，而高可用性是首先使用复制的关键原因。

更有效的策略包括以下步骤：

1. 拍摄一致的快照：大多数数据库允许创建一致的快照而无需锁定。此功能常用于备份。快照代表了领导者数据库在特定时刻的状态。
2. 将快照复制到新的关注者：将此快照传输到新的关注者。此步骤确保新的跟随者以接近领导者当前状态的数据状态开始。
3. 赶上最近的更改：快照到位后，新的追随者将连接到领导者并请求自拍摄快照以来发生的所有数据更改。这一步至关重要，需要将快照与领导者复制日志中的精确位置关联起来。此位置在 SQL 数据库中可能称为日志序列号或二进制日志协调器。
4. 加入集群：新的关注者赶上快照以来的所有更改后，它可以无缝集成到集群中并开始服务请求。

处理复制系统中的追随者中断
在强大的复制系统中，目标是即使单个节点遇到问题也能保持不间断运行。无论是由于系统崩溃还是网络中断，追随者节点中断都是常见场景，需要有效解决以确保系统弹性。关键是在不导致系统停机的情况下处理这些中断。

从者故障转移过程：

1. 本地更改日志：复制系统中的每个追随者都会在其本地磁盘上维护从领导者接收到的数据更改日志。该日志充当追随者已处理的所有事务和更新的记录。
2. 从中断中恢复：如果发生故障（例如系统崩溃或网络中断），关注者可以使用这些本地日志进行恢复。这些日志至关重要，因为它们包含直到故障点为止的所有更改的历史记录。
3. 重新连接和追赶：一旦关注者重新上线，它就可以确定在中断之前成功处理的最后一笔交易。有了这些信息，追随者就会重新连接到领导者，并请求自上次已知状态以来发生的所有更改。
4. 恢复操作：追随者赶上在中断期间错过的所有更新后，它可以无缝地继续接收来自领导者的新更改。此过程可确保追随者重新加入集群，而不会破坏整体系统性能或数据完整性。

处理复制系统中的领导者中断
与处理追随者中断相比，复制系统中的领导者故障转移是一个更加复杂的过程。它涉及提升其中一个追随者成为新的领导者，重新配置客户端以将所有写入操作定向到该新的领导者，并确保其他追随者开始从其接收数据。故障转移可以手动触发或自动触发。

自动故障转移过程通常涉及以下步骤：

1. 确定领导者故障：检测领导者故障可能具有挑战性，因为它可能是由于各种原因造成的，例如崩溃、断电或网络问题。没有万无一失的检测方法。通常，系统中的节点不断地相互发送心跳消息。如果节点在预定时间范围内没有响应，则假定该节点无法运行。
2. 选择新的领导者：选择新的领导者通常涉及追随者之间的选举过程。在某些系统中，专用控制器节点可能会做出此决定。新领导者的最佳候选人通常是拥有最新数据副本的人，以确保最小的数据丢失和连续性。
3. 重新配置系统：一旦选出新的领导者，系统需要重新配置：

• 客户端必须进行更新才能将写入请求发送给新的领导者。
• 必须调整复制机制，以便追随者开始接受新领导者的数据更改。
• 如果旧的领导者重新上线，它应该作为追随者重新融入系统，承认新的领导者。

故障转移过程中的潜在陷阱
分布式系统中的故障转移虽然对于维护可用性和弹性至关重要，但也充满了潜在的复杂性，特别是在使用异步复制时。

让我们探讨一下故障转移期间可能出现的一些常见问题：

1. 异步复制中的数据传输不完整：在异步复制中，新领导者有可能在失败之前尚未收到旧领导者的所有写入。当旧的领导者重新上线时，系统面临着未复制写入的困境。通常，这些写入会被丢弃以保持一致性，但这违反了客户端持久性原则。
2. 数据丢失和主键​​冲突的风险：在数据库内容需要与外部存储系统同步的系统中，丢弃写入操作尤其危险。例如，如果MySQL数据库中过时的领导者被升级，并且它对主键使用自动增量，则它可能会重新分配以前使用的键。这可能会导致严重的问题，例如将私人数据暴露给错误的用户。
3. 脑裂场景：当两个节点都认为自己是领导者时，就会出现脑裂情况。这是危险的，因为两个节点可能在没有解决冲突的过程的情况下独立接受写入，从而导致数据损坏或丢失。
4. 确定故障转移的正确时间：决定何时宣布领导者死亡是一个微妙的平衡。如果阈值太小，可能会发生不必要的故障转移；如果太长，系统可能需要很长时间才能恢复。

了解复制滞后及其影响
什么是复制延迟？

• 当将更改从领导者节点复制到跟随者节点时出现延迟时，就会出现复制延迟。这种情况在同步和异步复制中都可能发生，但在异步系统中更为明显。
• 示例：在同步系统中，如果领导者处理写入的速度很慢，则会延迟整个复制过程。在异步系统中，如果追随者无法以与生成日志一样快的速度处理复制日志，则追随者可能会落后于领导者。

读你自己写的

• 问题：用户更新数据（写入操作），但当他们立即读回数据时，更新尚未传播到所有副本，导致他们可能读取过时的数据。
• 示例：用户更新了他们的个人资料信息，但是当他们刷新页面时，不会显示新数据，因为为其读取请求提供服务的关注者尚未收到最新更新。

单调读取

• 问题：此问题涉及乱序读取更新，使更新看起来像是时间倒退的。
• 解决方案：确保用户始终从同一个副本读取可以解决此问题，因为它保证了用户看到的更新顺序。
• 示例：用户在其源中看到帖子，刷新页面，然后该帖子消失，因为它们由尚未收到最新更新的不同副本提供服务。

一致的前缀读取

• 问题：这是一种违反因果关系的行为，其中事件的顺序不正确。
• 示例：在聊天应用程序中，如果不同的副本正在提供数据，则用户可能会在看到问题本身之前先看到问题的响应。
• 解决方案：一致的前缀读取可以通过确保事件序列始终按照写入的顺序读取来防止这种异常，从而保持“发生在之前”的关系。事件序列始终按照写入的顺序读取，从而保持“之前发生”的关系。发生在之前”的关系。

这些问题凸显了确保复制系统中数据一致性的复杂性。每个问题都需要特定的策略来确保复制不会对用户体验或数据完整性产生负面影响。用户体验或数据完整性。数据的完整性。

（2）多领导者主主复制
在解开单领导者复制之后，我们遇到了它的致命弱点：所有写入的唯一领导者，容易受到网络故障的影响。

现在，我们转向多领导者复制——从单点写入权限到多点写入权限的飞跃，提高了分布式系统的写入弹性和灵活性。

让我们深入探讨多个领导者如何重新定义复制动态。

A. 多数据中心运营
多主复制在单个数据中心以外的场景中大放异彩，在这些场景中，好处大于复杂性。让我们来看看为什么它是多数据中心运营的明智选择，并将其与单领导者设置进行对比：

性能：

• 单个领导者：每次写入都必须与领导者一起传输到数据中心，这可能会增加延迟。
• 多领导者：每个数据中心在本地处理写入，并将它们异步复制到其他数据中心。此设置可以屏蔽用户的数据中心间延迟，从而提高性能。

• 单一领导者：如果领导者的数据中心发生故障，则必须提升另一个中心的追随者，从而导致中断。
• 多领导者：每个数据中心独立运行。如果发生中断，未受影响的中心会继续运行，离线副本会在恢复后赶上。

• 单一领导者：对数据中心间链接问题敏感，因为写入是通过这个可能不可靠的链接同步的。
• 多领导者：通常对网络问题更有弹性。其异步复制可以更好地容忍数据中心间连接的干扰。

示例：考虑一个全球电子商务平台。在多领导者设置中，每个地理区域都有自己的领导者。这意味着欧洲的用户可以体验到由欧洲本地数据中心处理的更快的写入操作，而不是等待数据往返于可能位于另一个大陆的中央领导者。在网络中断或数据中心中断期间，本地运营可以无缝继续，保持高质量的用户体验和一致的服务可用性。

B. 离线操作的客户端
在多领导者复制领域，无论互联网连接如何，设计用于连续操作的应用程序都具有一个突出的优势。

考虑一个日历应用程序，它允许用户即使在离线状态下也可以输入事件和会议。它的工作原理如下：

• 本地数据库作为领导者：每个用户的设备维护一个本地数据库，充当领导者。此设置使用户能够无缝添加或修改日历事件，而无需有效的互联网连接。
• 跨设备异步复制：每个设备上的日历与其他设备异步同步。这意味着复制延迟可能会持续数小时甚至数天，具体取决于设备重新连接到互联网的时间。

C. 协同编辑
在实时协作编辑的背景下——想想谷歌文档——多领导者复制成为一个关键角色。虽然与数据中心复制不同，但它与离线编辑用例有相似之处。

• 立即本地更新：当用户编辑文档时，更改会立即应用到其本地副本。
• 异步服务器同步：然后，这些更改会异步复制到服务器和参与编辑的其他用户。

另一种方法是最小化更改单元并放弃锁定，从而允许多个用户同时编辑。虽然这种方法提高了协作速度，但它带来了多领导者系统的典型挑战，包括解决冲突。

该用例体现了多领导者复制的多功能性，支持快速协作交互，同时平衡冲突管理和用户并发的复杂性。

解决多主复制中的写入冲突
想象一下维基百科上的一个场景，其中两个用户（用户 A 和用户 B）正在编辑同一篇文章。用户 A 将文章标题更改为“艺术史”，几乎同时，用户 B 将其更改为“艺术史”。这两项更改均在多领导者复制设置中的各自本地系统（或领导者）上成功进行。

以下是冲突的展开和解决方式：

1. 本地成功：用户 A 和用户 B 在其本地设备上都看到各自的标题更改成功。
2. 异步复制：然后将更改异步复制到托管页面“官方”版本的中央维基百科服务器。
3. 冲突检测：复制系统检测到冲突 - 同一篇文章有​​两个不同的标题。

A. 同步与异步冲突检测
在多领导者复制中，冲突检测与单领导者模型根本不同。让我们用一个简单的例子来说明这一点：

想象一下两个用户正在编辑共享的在线文档。在单个领导者数据库中，如果两个用户尝试同时编辑同一行，系统通常会通过以下任一方式处理此问题：

让第二个编写者等待，直到第一个编写者的更改提交。
中止第二个写入者的事务，提示他们稍后重试。
但是，在多领导者设置中，每个用户的写入操作最初在其本地副本上都是成功的。仅当更改异步复制到其他副本时，这些并发编辑之间的冲突才会变得明显。

为了解决这个问题，人们可能会考虑同步冲突检测，其中系统等待写入在所有副本之间复制，然后再向用户确认其成功。但是，这种方法本质上否定了多领导者复制的主要优势——允许独立和同时写入，以提高响应能力并减少延迟。面临的挑战是在有效管理潜在冲突的同时保持这一优势。

B. 避免冲突
多领导者复制中的一个简单策略是完全回避冲突。如果应用程序设计确保特定记录的所有写入一致地通过同一领导者，则可以实现这一点。

避免冲突的示例：考虑一个用户可以编辑自己的数据的应用程序。如果系统根据用户的地理位置将对用户数据的所有读写请求定向到同一个领导者，则本质上可以避免冲突。例如，欧洲的用户的所有数据将由欧洲数据中心处理。

回避策略的局限性：然而，这种方法有其局限性。如果需要更改记录的指定数据中心（可能是由于系统故障或因为用户已迁移到更靠近不同数据中心的区域），那么回避策略就会失效。在这种情况下，写入可能通过不同的领导者发生，系统需要具备处理这些情况引起的冲突的能力。

C. 走向一致的状态
在多领导者复制环境中，由于缺乏定义的写入顺序，在副本之间建立一致状态比在单领导者系统中更复杂。以下是一些实现一致性的策略：
为写入分配唯一 ID：

• 每个写操作都可以被赋予一个唯一的标识符，例如时间戳或长随机数。
• 然后系统选择具有最高 ID 的写入作为最终值。
• 使用时间戳时，这种方法称为“最后写入获胜”(LWW)。虽然简单，但 LWW 很容易丢失数据，因为它可能会忽略临时更新。

• 为每个副本分配一个唯一的 ID，并优先考虑来自编号较大的副本的写入。
• 此方法也可能导致数据丢失，因为它可能会忽略编号较低的副本的有效更新。

• 这种方法不是选择一种写入而不是另一种写入，而是合并所有冲突的值。
• 例如，如果两个写入发生冲突，系统可能会按字母顺序对值进行排序，然后将它们连接起来。

• 另一种策略是将冲突记录在数据结构中，并依靠应用程序代码来解决它。
• 这需要应用程序中的额外逻辑，但提供了更大的灵活性和对冲突解决的控制。

D. 自定义冲突解决逻辑
多领导者复制中的自定义冲突解决可以通过在应用程序代码中嵌入逻辑来实现，包括写入和读取操作：

• 写入时：当数据库检测到复制更改日志中存在冲突时，它可以触发冲突处理程序。该处理程序在应用程序代码中定义，可以决定如何解决冲突。例如，在共享文档编辑应用程序中，如果两个用户同时更改同一段落，冲突处理程序可能会通过将一个用户的编辑附加到另一个用户的编辑之后来合并这些更改。
• 读取时：可以通过将所有冲突版本存储在特定数据结构中来处理读取操作期间检测到的冲突。然后，应用程序可以将这些冲突呈现给用户以供手动解决或根据预定义的规则自动解决。例如，在任务管理应用程序中，如果两个用户为同一任务分配不同的优先级，则该应用程序可能会向查看该任务的第三个用户显示这两个选项，允许他们选择正确的优先级或自动选择最高的优先级。

通过利用自定义冲突解决逻辑，应用程序可以以最适合其特定操作和用户体验要求的方式处理冲突，从而确保最佳的数据完整性和用户满意度。

3、无领导无主复制
这种方法标志着与传统模型的显着背离。在这里，没有中心人物指挥交通。相反，客户端本身或协调器将写入直接发送到多个副本，但无需在基于领导者的系统中强制执行严格的顺序。

处理停机和数据恢复：解决无领导复制中的节点故障
想象一个具有三个副本的基于领导者的系统。如果出现故障（例如由于崩溃或系统重新启动），系统会执行故障转移以保持平稳运行。现在，让我们将其与无领导系统进行对比。在这里，没有故障转移。相反，当客户端想要写入某些内容时，它会将请求发送到所有三个副本。假设在我们的例子中，三个副本中的两个接受并写入请求，但其中一个不可用，错过了该请求。在无领导的设置中，如果大多数人（例如我们示例中的三分之二）承认写入成功，则通常被认为是足够的。

但是，当不可用的节点重新上线时会发生什么？它可能开始读取数据并最终得到陈旧的信息——它在宕机时丢失的数据。为了避免这种情况，客户端将读取请求发送到多个副本，然后选择具有最新响应的节点。这样，即使一个节点有陈旧的数据，客户端仍然可以从其他节点获取最新的信息。

读修复和反熵
复制系统应确保最终所有数据都复制到所有副本。当节点重新上线后，如何获取最新数据？

读取修复：想象一下客户端从多个节点请求数据。如果它从副本 3 等处获得过时的响应，它可以立即将更新后的值写回该副本。此方法对于经常读取的数据有效。例如，如果流行产品的价格更新，读取修复可确保所有副本快速反映新价格。

1. 反熵：这是一种更被动的方法。数据库不断运行后台进程来查找副本之间的差异。然后他们同步数据，但不按任何特定顺序。与基于领导者的系统中的复制日志不同，反熵可能会在复制数据之前导致显着的延迟。例如，如果很少更新的用户配置文件发生更改，则所有副本可能需要一些时间才能显示新信息。

读和写的法定人数
读写仲裁的概念是无领导者复制系统的基础。让我们通过一个例子来深入研究一下。

想象一下您有一个具有五个副本的分布式数据库。在此系统中，为了确保一致性，您可以为读取和写入操作定义仲裁。假设您将写入仲裁 (W) 设置为 3，将读取仲裁 (R) 设置为 3。这意味着要使写入操作被视为成功，5 个副本中至少有 3 个必须确认该写入。同样，为了使读取操作可靠，它必须从至少 3 个副本收集数据。

现在，考虑一个客户端将数据写入系统的场景。写请求被发送到所有五个副本，但只需要任意 3 个副本的确认即可继续。这确保了即使 2 个副本出现故障或速度缓慢，系统仍然可以有效运行。

对于读取操作，客户端将查询至少 3 个副本并使用响应中的最新数据。这种方法有助于缓解过时数据的问题 - 如果一个副本尚未更新，则具有最新数据的其他副本将确保客户端收到最新信息。

通过以这种方式设置仲裁，您可以在可用性和一致性之间取得平衡。如果W + R > N（副本总数），系统保证强一致性，这意味着每次读取都会收到最近的写入。在我们的例子中，W(3)+R(3)大于N(5)，从而保证了强一致性。

这种仲裁模型是无领导系统的关键，即使面对节点故障或网络问题，也能提供灵活性和鲁棒性。它允许系统继续平稳运行，同时确保数据完整性和一致性。

群体一致性的灰色地带：理论与现实的结合
仲裁一致性虽然在许多场景中有效，但也有其局限性，特别是当 W（写入仲裁）+ R（读取仲裁）< N（副本总数）时。此设置优先考虑延迟而不是绝对数据准确性，可能导致读取过时。

让我们分解一些边缘情况，即使 W + R > N 也可能导致数据过时：

• 草率仲裁：当写入仲裁最终位于与读取仲裁不同的节点上时，就会发生这种情况，导致无法保证重叠。因此，读取可能无法获取最近的写入，从而导致数据过时。
• 读取期间的并发写入：如果写入与读取同时发生，则写入可能仅反映在某些副本上。这种不确定性使得我们不清楚读取是检索旧数据还是新数据。
• 部分写入成功：想象这样一个场景：写入在某些副本上成功，但在其他副本上失败，并且整体操作在少于“W”个节点上被视为成功，而无需回滚。在这种情况下，后续读取可能会也可能不会报告该写入的值，从而造成不一致。
• 节点故障和数据恢复：如果承载新值的节点发生故障，并且从具有旧值的副本中恢复其数据，则存储新值的副本数量可能会低于“W”。仲裁条件的这种破坏可能会导致读取过时。

尽管理论上保证仲裁设置可确保读取最新数据，但实际情况表明这并不总是那么简单。例如，Dynamo 风格的数据库通常针对可以容忍最终一致性的用例进行优化。

从本质上讲，虽然基于仲裁的系统旨在平衡延迟和数据准确性，但这些边缘情况凸显了了解这种方法在实际应用中的细微差别和潜在局限性的重要性。

密切关注数据新鲜度：监控陈旧情况
运行分布式系统时，监控返回的数据是新鲜的还是陈旧的数据至关重要。即使您的应用程序可以处理一些过时的读取，了解复制的运行状况也至关重要。如果落后，需要及时向开发人员发出警报。

在基于领导者的系统中，监控更加简单。数据库通常提供复制滞后的指标。由于写入以相同的顺序应用于领导者和追随者，因此每个节点在复制日志中都有一个特定的位置。通过将追随者的当前位置与领导者的当前位置进行比较，您可以有效地衡量滞后。

但是，在无领导者复制系统中，事情变得更加棘手。写入不是按固定顺序应用的，这使得监控陈旧性变得困难。尽管已经对计算此类设置中的陈旧性进行了一些研究，但它尚未得到广泛应用。

因此，虽然基于领导者的系统有一种明确的方法来衡量数据新鲜度，但无领导者系统需要更多创新的方法来确保您始终使用最新的信息。

草率的仲裁和暗示的交接：数据库弹性策略
想象一下，您正在运行一个分布在多个节点（服务器）上的数据库，并且其中一个节点突然变慢或出现故障。通过正确设置仲裁，您的数据库可以继续正常运行，而无需完全故障转移。这是因为它不必等待每个节点确认每个写入或读取 - 只需满足法定人数即可。

但这里有一个问题：法定人数并不完美。假设发生网络故障，客户端突然无法到达足够的节点来形成法定人数。其他客户端可能没问题，但对于这个不幸的客户端来说，这些节点就像消失了一样。

现在，想象一个大型集群，其中客户端在中断期间仍然可以连接到某些数据库节点，只是不适合法定人数。系统应该做什么？有两个主要选项：

谨慎行事，对于无法达到法定人数的请求返回错误。
或者，顺其自然并接受写入，将它们记录在任何可访问的节点上，即使它们不是通常的嫌疑对象。
第二种选择就是我们所说的“草率法定人数”。在这里，写入和读取仍然需要成功响应，但这些响应可以来自任何可用节点，而不仅仅是指定节点。这就像当主要表演者无法上场时，有一个后备舞团介入——演出继续进行，只是有点不同。

这种方法在面对网络问题时提供了弹性，确保数据写入某个地方，即使它不是理想的位置。这是一个实际的权衡，优先考虑持续运行而不是严格遵守通常的节点阵容。

那么，当导致法定人数草率的网络问题得到解决后会发生什么？这就是“暗示切换”发挥作用的地方。这就像一场混乱的聚会后的清洁人员。

当网络中断解决后，我们的数据库节点再次聊天，任何暂时被错误节点接受的写入现在都会传递到其合法的主节点。这就像将错误投递的邮件转发到正确的地址。

当您需要高写入可用性时，草率仲裁的概念非常方便。这就像能够将信件放入任何邮箱，并知道它最终会到达正确的地方。但有一个权衡：虽然任何节点都可以进行写入，但这可能意味着客户端并不总是获得最新的读取。这有点像从邻居那里听到消息，而不是直接从消息来源处听到消息——通常是可靠的，但有时您可能无法获得最新的更新。

简而言之，当网络变得挑剔时，草率的法定人数可以让事情继续进行，并暗示一旦事情恢复正常，交接就会清理干净。它们共同帮助维持数据库世界中可用性和一致性之间的平衡。

并发写入难题
当我们结束对无领导复制的探索时，是时候触及我们将在下一篇文章中深入探讨的关键挑战：并发写入的复杂性。当两个客户端尝试同时写入同一个密钥时，就会出现这种情况，这是可能导致数据冲突的常见情况。

在无领导系统中，每个节点都可以独立接受写入请求，这意味着当这些节点尝试协调其数据时可能会出现冲突。与指定领导者来管理写入的系统不同，无领导者架构需要不同的方法来处理这些冲突。

了解冲突如何在无领导的系统中发生以及解决冲突的各种策略至关重要。有一些方法，例如“最后写入获胜”、使用“发生之前”关系以及捕获和合并冲突数据的技术。