分布式数据库模拟器

什么是分布式数据库？

分布式数据库将数据分布在不同位置的多个服务器（节点）上。CAP定理指出，你只能保证三个特性中的两个：一致性（每次读取都能看到最新的写入）、可用性（每个请求都能获得响应）和分区容错性（系统在网络分裂时仍能工作）。

为什么这很重要？从Google到Netflix，每个主要的互联网服务都依赖分布式数据库。理解一致性和可用性之间的权衡，对于构建服务数十亿用户的可靠、可扩展系统至关重要。

📖 深入了解

类比 1

想象一下一个在 5 个城市设有分支机构的图书馆系统，所有分支机构都共享相同的目录。当有人在 A 分行借书时，所有其他分行都需要更新他们的记录。如果分支 C 的电话线路出现故障（网络分区），分支 C 可能仍会显示该书可用 — 这是一致性问题。您可以锁定所有借贷，直到分支 C 重新连接（选择一致性），或者让每个分支保持独立借贷并稍后进行协调（选择可用性）。

类比 2

想象一下与不同国家的朋友进行群聊。当您发送消息时，每个人都应该以相同的顺序看到它。但如果某人的互联网掉线，他们就会错过消息，并可能回复过时的信息，从而产生冲突的对话线程。分布式数据库大规模地面临着这个确切的问题，并使用矢量时钟和 CRDT 等技术来解决每个人重新连接时的混乱情况。

🎯 模拟器提示

初学者

从 5 个节点和复制因子 3 开始 — 这意味着每条数据都存储在 5 个节点中的 3 个上

中级

比较写入一致性 ALL 与 ONE — ALL 速度较慢，但保证每个副本都拥有最新数据

专家

禁用矢量时钟并在分区期间触发并发写入，以观察未解决的冲突

📚 术语表

CAP Theorem

布鲁尔定理指出，分布式系统最多可以提供三个保证中的两个：一致性、可用性和分区容错性。在网络分区期间，您必须在 C 和 A 之间进行选择。

Replication Factor

整个集群中维护的每条数据的副本数量。复制因子为 3 意味着每次写入都存储在 3 个不同的节点上。

Quorum

大多数副本必须确认读取或写入操作才能成功。对于 RF=3，仲裁数为 2。仲裁读取与仲裁写入相结合可保证一致性。

Consistency Level

确定在读取或写入被视为成功之前必须响应多少个副本。 ONE 速度最快，但可能返回过时的数据； ALL 是最慢的，但始终一致。

Network Partition

网络通信故障，将集群分成两组或多组无法相互通信的节点，迫使在一致性和可用性之间做出选择。

Split-Brain

一种危险情况，网络分区导致两组节点独立接受冲突的写入，并相信自己是权威集群。

Vector Clock

一种跟踪分布式节点间事件的因果顺序的数据结构。每个节点维护一个逻辑计数器，比较矢量时钟可以揭示事件是否因果相关或并发。

CRDT

无冲突复制数据类型 - 一种数据结构，旨在使用交换性等数学属性，使不同副本上的并发更新始终收敛到相同状态，而无需协调。

Last-Write-Wins (LWW)

一种简单的冲突解决策略，其中具有最新时间戳的写入获胜。易于实现，但可以默默地丢弃并发更新。

Gossip Protocol

一种点对点通信模式，其中每个节点定期与随机对等点交换状态信息，最终将更新传播到所有节点 - 受到谣言传播方式的启发。

Anti-Entropy

后台修复过程，节点定期将其数据与对等节点进行比较并同步差异，即使在发生故障后也确保最终的一致性。

Merkle Tree

哈希树数据结构，用于有效检测副本数据之间的差异。节点首先比较根哈希，然后深入查找并仅修复不同的特定键。

Tombstone

指示数据已被删除的标记。逻辑删除必须保留一段 TTL 时间，以防止当具有旧数据的分区节点重新加入集群时已删除的数据重新出现。

Eventual Consistency

一致性模型保证如果没有进行新的更新，所有副本最终将收敛到相同的值。传播延迟是收敛之前的时间。

Write-Ahead Log (WAL)

一种持久性技术，其中更改在应用于数据库之前写入顺序日志，通过重播日志实现崩溃恢复。

🏆 关键人物

Eric Brewer (2000)

在加州大学伯克利分校提出了 CAP 定理，通过证明同时保证一致性、可用性和分区容错性的不可能性，从根本上塑造了分布式数据库设计

Leslie Lamport (1998)

创建了 Paxos 共识算法，并开创了分布式系统理论，其中包括逻辑时钟、Lamport 时间戳和拜占庭将军问题等概念

Diego Ongaro (2014)

在斯坦福大学设计了 Raft 共识算法，使分布式共识对于 etcd 和 CockroachDB 等现实系统来说变得易于理解和实用

Werner Vogels (2007)

领导了 Amazon Dynamo 的设计，该产品引入了一致的哈希、矢量时钟和草率仲裁 — 启发了 Cassandra、Riak 和整个 NoSQL 运动

Jeff Dean & Wilson Hsieh (2012)

共同设计了 Google Spanner，这是第一个使用 TrueTime API 和 GPS/原子钟同步实现外部一致事务的全球分布式数据库

Marc Shapiro (2011)

INRIA 首创的无冲突复制数据类型 (CRDT)，为无协调的最终一致性提供数学基础

🎓 学习资源

Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services [paper]
CAP 定理的形式证明，建立了分布式系统的基本不可能性结果（ACM SIGACT News，2002）
Dynamo: Amazon's Highly Available Key-value Store [paper]
Amazon 关于使用一致散列、矢量时钟和草率仲裁的最终一致分布式存储的影响力论文 (SOSP 2007)
Spanner: Google's Globally Distributed Database [paper]
Google 基于 TrueTime 的全球一致数据库通过 GPS 和原子钟同步实现外部一致性 (OSDI 2012)
In Search of an Understandable Consensus Algorithm (Raft) [paper]
Raft 共识算法旨在易于理解，现已用于 etcd、CockroachDB 和 TiKV（USENIX ATC 2014）
Designing Data-Intensive Applications [article]
Martin Kleppmann 的分布式系统基础知识、复制、分区和一致性模型综合指南
Jepsen.io [article]
Kyle Kingsbury 对真实故障条件下分布式数据库正确性声明的严格测试和分析
The Raft Consensus Algorithm Visualization [article]
Raft 共识算法的交互式可视化，包括逐步的领导者选举和日志复制

💬 给学习者的话

分布式数据库是现代互联网的支柱。每次您在社交媒体上发帖、播放视频或进行在线购买时，数十个分布式数据库节点都会在幕后进行协调。 CAP 定理告诉我们，在网络出现故障的世界中，完美是不可能的，而工程就是要做出明智的权衡。您在这里探索的概念——复制、共识、冲突解决——与谷歌、亚马逊和 Netflix 的工程师每天解决的挑战相同。了解这些基础知识将使您深入了解数字世界的实际运作方式，并可能激励您构建下一代弹性数据系统。