数据工程CAP定理初学者指南
我们在处理数据激增的分布式数据库方面取得了重大进步。这使我们能够以较低的延迟处理增加的流量，使数据库系统更容易扩展，在复制方面提供更好的容错能力等等。
该的NoSQL数据库已在不经意间一直处于这种转变在分布式数据库领域的最前沿。他们一直在为您提供处理数据方面的灵活性。再加上那里有很多！
但是，真正的问题是要使用哪个？这个问题的答案不仅在于这些数据库的性质，还在于对基本定理的理解。自从这样的数据库出现在数据库领域以来，一个定理就引起了新的关注。是的，我说的是CAP定理！
了解CAP定理
简而言之，CAP定理使您可以确定当少数数据库服务器由于系统中的某些故障而拒绝相互通信时，如何处理分布式数据库系统。但是，存在一些误解。因此，在本文中，我们将尝试理解CAP定理以及它如何帮助选择正确的分布式数据库系统。
但是首先，让我们对分布式数据库系统有一个基本的了解。
目录
什么是分布式数据库系统
通过示例了解CAP定理
了解CAP定理的术语
什么是CAP定理？
通过MongoDB了解CP
了解Cassandra的AP
分布式数据库系统
在NoSQL类型的分布式数据库系统中，多台计算机或节点一起工作，可以给用户留下一个工作数据库单元的印象。他们将数据存储在这些多个节点中。这些节点中的每一个都运行数据库服务器的实例，并且它们以某种方式相互通信。
当用户想要写入数据库时??，数据将被适当地写入分布式数据库中的节点。用户可能不知道数据写入的位置。类似地，当用户想要检索数据时，它会连接到系统中最近的节点，该节点将为该节点检索数据，而用户并不知道这一点。
这样，用户就可以简单地与系统进行交互，就好像它与单个数据库进行交互一样。节点内部相互通信，从相关节点检索用户正在寻找的数据，或存储用户提供的数据。
现在，分布式系统的好处非常明显。随着用户流量的增加，我们可以通过向系统添加更多节点来轻松扩展数据库。由于这些节点是商用硬件，因此与分别向每个节点添加更多资源相比，它们相对便宜。也就是说，水平缩放比垂直缩放便宜。
这种水平扩展使数据复制更便宜，更容易。这意味着，现在，系统可以通过在复制节点之间适当地分配流量来轻松处理更多的用户流量。
分布式数据库垂直扩展与水平扩展
因此，现在真正的问题出在为任务选择合适的分发系统时。要回答这个问题，我们需要了解CAP定理。
通过示例了解CAP定理
CAP定理（也称为Brewer定理）代表一致性，可用性和分区容限。但是，让我们尝试通过一个例子来理解它们。
可用性
想象一下，您的城市中有一家非常受欢迎的移动运营商，而您因为它提供的惊人计划而成为其客户。除此之外，他们还提供了出色的客户服务，您可以随时致电并快速有效地回答您的疑问和疑虑。每当客户打电话给他们时，移动运营商就可以将他们连接到他们的客户服务运营商之一。
客户能够获取他/他所需的有关其帐户的任何信息，例如余额，使用情况或其他信息。我们之所以称其为“可用性”，是因为每个客户都可以连接到运营商并获取有关用户/客户的信息。
CAP定理可用性
一致性
现在，您最近搬到了这座城市的新房子，并且想要更新在移动运营商处注册的地址。您决定致电客户服务运营商并与他们进行更新。打电话时，您可以与接线员联系。该操作员在系统中进行相关更改。但是放下电话后，您会意识到您告诉了他们正确的街道名称，但是却是旧门牌号（旧习惯很难改掉！）。
因此，您会疯狂地再次致电客户服务中心。这次打电话时，您与其他客户服务接线员联系，但是他们也可以访问您的记录，并且知道您最近更新了地址。他们对门牌号进行了相应的更改，其余地址与您告诉上一位接线员的地址相同。
我们称此为“一致性”是因为即使您连接到其他客户服务运营商，他们也可以检索相同的信息。
CAP定理一致性
分区容限
最近，您注意到您当前的移动方案不适合您。您不再需要访问那么多移动数据，因为您在家中和办公室都拥有良好的Wi-Fi设施，并且几乎不走到任何地方。因此，您要更新您的移动计划。因此，您决定再次致电客户服务中心。
这次与操作员联系时，他们告诉您由于某些问题他们无法更新其记录。因此，与操作员共享的信息可能不是最新的，因此他们无法更新该信息。我们可以在这里说服务已损坏或没有分区容限。
CAP定理划分
了解CAP定理的术语
现在，让我们逐个讨论这些术语，并尝试以更正式的方式理解它们。
一致性
一致性意味着用户无论在系统上连接到哪个节点，都应该能够看到相同的数据。此数据是写入系统的最新数据。因此，如果节点上发生了写操作，则应将其复制到其所有副本。这样，只要用户连接到系统，他们就可以看到相同的信息。
但是，拥有一个能够在瞬间和全局范围内保持一致性的系统几乎是不可能的。因此，目标是使此过渡足够快，以使其几乎不被注意到。
当要求所有客户端或用户查看同一数据时，一致性很重要。这在处理财务或个人信息的地方很重要。例如，无论您是从PC，平板电脑还是智能手机上查看，您的银行帐户都应反映相同的余额！
可用性
可用性意味着来自用户的每个请求都应引起系统的响应。无论用户想要读取还是写入，即使操作失败，用户也应该获得响应。这样，每个操作都必然会终止。
例如，当您访问银行的ATM机时，便可以访问您的帐户及其相关信息。现在，即使您使用其他自动柜员机，您仍然应该能够访问自己的帐户。如果您只能从一个ATM而不是另一个ATM访问您的帐户，则意味着该信息不适用于所有ATM。
当要求客户端或用户始终能够访问数据（即使数据不一致）时，可用性至关重要。例如，即使您由于某些网络故障正在查看过时的状态，也应该能够查看朋友的Whatsapp状态。
分区容差
分区是指分布式系统内节点之间的通信中断。这意味着，如果一个节点无法从系统中的另一个节点接收任何消息，则两个节点之间将存在一个分区。分区可能是由于网络故障，服务器崩溃或任何其他原因。
因此，如果分区意味着通信中断，那么分区容忍度将意味着即使系统中存在分区，系统仍应能够正常工作。这意味着，如果节点无法通信，则该节点的副本之一应该能够检索用户所需的数据。
这是通过将记录的副本保留在多个不同的节点中来处理的。这样，即使发生分区，我们也能够从其副本中检索数据。正如您已经猜到的那样，分区容忍度对于任何分布式数据库系统都是必须的。
什么是CAP定理？
在上一节中，您了解了CAP定理中每个术语的含义。现在让我们了解定理本身。
CAP定理指出，发生分区时，分布式数据库系统必须在一致性和可用性之间进行权衡。
由于网络故障或某些其他原因，分布式数据库系统在实际系统中必然具有分区。因此，分区容限是我们在构建系统时无法避免的属性。因此，分布式系统将选择放弃一致性或可用性，而不是放弃分区容限。
例如，在分布式系统中，如果两个节点之间发生分区，则不可能在两个节点上都提供一致的数据，也无法提供完整数据。因此，在这种情况下，我们选择在一致性或可用性上进行折衷。因此，NoSQL分布式数据库的特征是CP或AP。CA类型数据库通常是在单个节点上工作且不提供分发的整体数据库。因此，它们不需要分区容限。
通过MongoDB了解CP
让我们尝试在MongoDB的帮助下了解分布式系统决定放弃分区时的可用性时的工作方式。
CAP定理CP与Mongodb
MongoDB是一个NoSQL数据库，它以JSON文件的形式将数据存储在一个或多个主节点中。每个主节点都有多个副本集，这些副本集使用其各自主节点的操作日志文件异步更新。系统中的副本集节点向其他每个节点发送心跳（ping），以跟踪其他副本或主节点是否处于活动状态或死亡。如果10秒钟内未收到心跳，则将该节点标记为不可访问。
如果主节点不可访问，则辅助节点之一需要成为主节点。直到从辅助节点中选举出一个新的主节点，系统对用户仍然无法进行任何新的写查询。因此，MongoDB系统表现为一致性系统，并在分区期间损害了可用性。
了解Cassandra的AP
现在，让我们来看看系统如何在一致性上妥协。为此，我们将看一下Cassandra数据库，它被称为高可用性数据库。
Cassandra是一个点对点系统。它由系统中的多个节点组成。并且每个节点都可以接受来自用户的读取或写入请求。Cassandra在单独的节点中维护多个数据副本。这为它提供了一个无主控节点架构，其中有多个故障点而不是一个故障点。
复制因子确定数据的副本数。如果复制因子为3，那么我们将以顺时针方式在三个节点中复制数据。
CAP_theorem AP与Cassandra
可能会发生以下情况：发生分区，并且副本未获得数据的更新副本。在这种情况下，副本节点仍然对用户可用，但数据将不一致。但是，Cassandra还提供了最终的一致性。这意味着，所有更新最终将到达所有副本。但是与此同时，它允许相同数据的不同版本临时存在。直到我们将它们更新为一致状态。
因此，通过允许节点在整个系统中都可用，并暂时允许系统中存在的不一致数据，Cassandra是一个影响一致性的AP数据库。
题库