Cassandra 基础

Cassandra 是一个 NoSQL 分布式数据库。根据设计，NoSQL 数据库是轻量级、开源、非关系型且高度分布式的。其优势包括水平可扩展性、分布式架构以及灵活的模式定义方法。

NoSQL 数据库能够快速、灵活地组织和分析海量、异构的数据类型。随着大数据的出现以及云中数据库快速扩展的需求，这一点在近年来变得越来越重要。Cassandra 是众多 NoSQL 数据库中的一种，它解决了以前数据管理技术（如 SQL 数据库）的限制。

Cassandra 的一个重要属性是其数据库是分布式的。这带来了技术和业务上的优势。Cassandra 数据库在应用程序承受高压力时可以轻松扩展，并且分布式还可以防止任何给定数据中心的硬件故障导致数据丢失。分布式架构还带来了技术上的强大功能；例如，开发人员可以独立调整读查询或写查询的吞吐量。

“分布式”意味着 Cassandra 可以运行在多台机器上，同时对用户来说就像一个统一的整体。虽然将 Cassandra 作为单个节点运行意义不大，但这样做非常有助于帮助你了解它的工作原理。但要充分利用 Cassandra，你应该在多台机器上运行它。

由于 Cassandra 是一个分布式数据库，因此它可以（通常也确实）拥有多个节点。节点代表 Cassandra 的单个实例。这些节点通过称为“Gossip”的协议相互通信，这是一种计算机对等通信过程。Cassandra 还具有无主架构——数据库中的任何节点都可以提供与任何其他节点完全相同的功能——这有助于提高 Cassandra 的健壮性和弹性。多个节点可以在逻辑上组织成一个集群或“环”。你还可以拥有多个数据中心。

Cassandra 受欢迎的原因之一是它使开发人员能够使用现成的硬件动态扩展其数据库，并且不会出现停机时间。你可以在需要时进行扩展——也可以缩减，如果应用程序需求表明需要这样做。

也许你习惯了 Oracle 或 MySQL 数据库。如果是这样，你就会知道，要扩展它们以支持更多用户或存储容量，你需要添加更多 CPU 能力、RAM 或更快的磁盘。每项都需要花费大量的资金。然而：最终你仍然会遇到一些上限和限制。

相比之下，Cassandra 使得增加它可以管理的数据量变得很容易。由于它基于节点，因此 Cassandra 可以水平扩展（也称为横向扩展），使用更低成本的商品硬件。要将容量或吞吐量翻倍，只需将节点数量翻倍即可。就这么简单。需要更强大的功能？添加更多节点——无论是 8 个还是 8000 个——并且不会出现停机时间。你还可以根据需要灵活地缩减规模。

这种线性可扩展性实际上是无限的。这种能力已成为 Cassandra 的主要优势之一。

在 Cassandra 中，数据本身会自动分布，并具有（积极的）性能影响。它使用分区来实现这一点。每个节点都拥有特定的一组令牌，Cassandra 根据这些令牌在整个集群中的范围来分布数据。分区键负责在节点之间分布数据，对于确定数据位置至关重要。当数据插入集群时，第一步是对分区键应用哈希函数。输出用于确定哪个节点（基于令牌范围）将获得数据。

当数据进来时，数据库的协调器会承担将数据分配到给定分区（我们称之为分区 59）的任务。请记住，集群中的任何节点都可以承担协调器的角色。正如我们之前提到的，节点之间会进行“Gossip”；在此过程中，它们会相互通信以了解哪个节点负责哪些范围。因此，在我们的示例中，协调器会进行查找：哪个节点拥有令牌 59？当它找到正确的节点时，它会将该数据转发到该节点。拥有该范围数据的节点称为副本节点。一条数据可以复制到多个（副本）节点，从而确保可靠性和容错性。到目前为止，我们的数据只复制到一个副本。这表示复制因子为 1，即 RF = 1。

协调器节点不是一个单一的位置；如果它是，那么系统将很脆弱。它只是在那一刻接收请求的节点。任何节点都可以充当协调器。

一条数据可以复制到多个（副本）节点，从而确保可靠性和容错性。Cassandra 支持复制因子 (RF) 的概念，它描述了数据库中应该存在多少份数据副本。到目前为止，我们的数据只复制到一个副本 (RF = 1)。如果我们将它提高到复制因子为 2 (RF = 2)，那么数据也需要存储在第二个副本上——因此每个节点除了其主范围之外，还负责一个次要范围的令牌。复制因子为 3 确保有三个节点（副本）覆盖该特定令牌范围，并且数据存储在另一个节点上。

Cassandra 的分布式特性使其更具弹性和性能。当我们对同一数据拥有多个副本时，这一点真正发挥作用。这样做有助于系统在出现问题时自我修复，例如，如果节点出现故障、硬盘驱动器出现故障或 AWS 重置实例。复制确保数据不会丢失。如果对数据发出请求，即使我们的一个副本出现故障，另外两个副本仍然可以提供数据来满足请求。协调器还会为该数据存储一个“提示”，当出现故障的副本恢复时，它会找到它错过的内容，并赶上另外两个副本的速度。不需要手动操作，这完全是自动完成的。

使用多个副本也具有性能优势。因为我们不限于单个实例，所以我们可以访问三个节点（副本）来为我们的操作提供数据，我们可以在这三个节点之间进行负载均衡以实现最佳性能。

Cassandra 会自动将该数据复制到你的不同数据中心。你的应用程序可以将数据写入美国西海岸的 Cassandra 节点，而该数据会自动在亚洲和欧洲的数据中心节点中可用。这具有积极的性能优势——尤其是在你支持全球用户群的情况下。在一个依赖云计算和快速数据访问的世界里，没有用户会因距离而受到延迟的影响。

我们一直在讨论分布式系统和可用性。如果你熟悉 CAP 定理，Cassandra 默认情况下是一个 AP（可用分区容忍）数据库，因此它是“始终在线”的。但你确实可以在每个查询的基础上配置一致性。在这种情况下，一致性级别表示在操作被认为成功之前，必须向协调器确认读或写操作的 Cassandra 节点的最小数量。一般来说，你将根据你的复制因子选择一致性级别 (CL)。 对于下面的示例，我们的数据复制到三个节点。我们有一个 CL=QUORUM（Quorum 指多数，在本例中为 2 个副本或 RF/2 +1），因此协调器需要从两个副本获得确认才能使查询被认为成功。

与其他计算任务一样，学习如何调整此功能以获得理想的性能、可用性和数据完整性可能需要一些技巧——但能够以如此细粒度的方式控制它意味着你可以非常详细地控制部署。

最终，Cassandra 与部署无关。它不在乎你把它放在哪里——本地、云提供商、多个云提供商。你可以将它们组合起来用于单个数据库。这为软件开发人员提供了最大的灵活性。