Module 03 · Introducing Apache Cassandra: An Open-Source NoSQL Database

Key Features of Apache CassandraApache Cassandra 关键特性概述

Coursera ↗

欢迎观看关于 Apache Cassandra 关键特性的视频。在本视频中，您将能够：

解释 分布式 和 去中心化 的含义，
描述 Cassandra 中的数据复制机制，
区分 可用性 和 一致性，
解释 Cassandra 的可扩展性，
了解 Cassandra 如何提供高写入吞吐量，
解释 CQL 语言。

分布式与去中心化

分布式 和 去中心化 是 Cassandra 的核心特性之一。

分布式架构

Cassandra 的集群可以运行在多台机器上，但对用户和应用来说，它们表现得像一个统一的整体。Cassandra 的架构设计使得应用客户端和服务器可以提供足够的信息，将用户请求最优地路由到集群中的正确节点。

用户可以将数据写入集群中的任何节点，Cassandra 会理解并处理请求。

去中心化架构

Cassandra 是去中心化的，意味着每个节点在集群中都是平等的，没有主节点或从节点。所有节点都采用对等通信协议，并通过 gossip 协议保持同步。

数据分配与复制

在 Cassandra 中，数据的分配是基于查询和分区键的。

分区键和数据分配

例如，如果您有一个包含用户信息的数据集，并且要按 state 查询所有用户，可以通过将 state 列声明为分区键来分配数据。Cassandra 会基于分区键对数据进行分配，然后通过哈希和预定义的令牌分配策略，将数据分布到集群中的节点。

数据复制

Cassandra 使用复制机制确保数据冗余和高可用性。复制因子（Replication Factor）决定了每个数据分区的副本数量。数据会在集群中的多个节点之间按顺时针方向进行复制，并考虑到节点所在机架和数据中心的布置。

可用性与一致性

Cassandra 采用 最终一致性，即它优先保证系统的 高可用性，而牺牲部分一致性。

最终一致性：数据在一定时间内可能不一致，但最终会一致。
可调一致性：Cassandra 允许开发者根据需求调整一致性的级别，从 强一致性 到 最终一致性。

CAP 定理

根据 CAP 定理，分布式系统不能同时保证 一致性 和 可用性。Cassandra 选择 可用性，即使在某些节点不可用时，系统仍能响应请求，尽管返回的数据可能不一致。

Cassandra 的可扩展性

Cassandra 是 线性可扩展 的，意味着随着节点的增加，性能也会相应地线性增长。您可以通过简单地添加新节点来扩展 Cassandra 集群，并且新节点立即开始服务。

平行写入：Cassandra 会并行地将数据写入集群中的所有节点，确保高写入吞吐量。
无需重启：添加或删除节点时，集群不会中断运行，新的节点会自动接管一部分负载。

Cassandra 提供高写入吞吐量

Cassandra 的写入操作在节点级别是 内存操作，即写入操作首先发生在内存中，然后顺序写入磁盘。写入操作会以追加的方式存储在磁盘上，数据会通过压缩过程在后续进行整理。

CQL 语言

CQL（Cassandra Query Language） 是 Cassandra 用于数据定义和操作的语言，语法类似于 SQL，这使得开发人员可以快速上手。

CQL 支持操作如：CREATE TABLE、INSERT、UPDATE、DELETE、ALTER 等。
尽管 CQL 语法上与 SQL 类似，但 Cassandra 在读写操作的执行方式上与关系型数据库有很大不同。

Cassandra 的优势

分布式和去中心化架构：Cassandra 的所有节点都是平等的，确保了高可用性和扩展性。
高可用性与故障容忍：Cassandra 设计上保证 高可用性，即使在部分节点不可用时，系统仍能保持运行。
高写入吞吐量：Cassandra 支持极高的写入吞吐量，适合写密集型应用。
水平扩展性：通过添加节点，Cassandra 能够轻松地扩展集群的存储和计算能力。

Cassandra 的最佳使用场景

Cassandra 最适合以下场景：

写密集型应用：如记录用户点击流、交易数据等。
需要高可用性和高吞吐量的应用：如 Netflix、Spotify、Uber 等全球在线服务。
时间序列数据：如天气更新、传感器数据等，数据以追加的方式存储。
地理分布式应用：适用于全球访问的应用，支持多数据中心部署。

总结

通过本视频，您了解了：

Cassandra 是一个 分布式 和 去中心化 的数据库，提供 高可用性、高写入吞吐量 和 水平扩展性。
数据是根据 分区键 分配的，并且通过复制因子保证冗余和高可用性。
Cassandra 提供 最终一致性，允许根据需要调整一致性级别。
CQL 是 Cassandra 的查询语言，语法类似于 SQL，但写操作和读操作的执行方式有所不同。

核心特性深度解析

1. 分布式 (Distributed) vs. 去中心化 (Decentralized)

通俗理解：
- 分布式： 一个任务由多台机器（一个集群）共同完成。就像一个大公司，有市场部、技术部、销售部等不同部门分工协作。Cassandra就是一个分布式数据库，数据被分片存储在多台服务器上。
- 去中心化： 在这个集群中，没有“总部”或“中央指挥部”。每台服务器（节点）的角色和地位都是完全相同的（Peer-to-Peer）。没有传统数据库中的“主节点（Master）”和“从节点（Slave）”之分。
架构师视角：
- 优势： 极高的可用性和可维护性。任何节点都可以接收客户端请求（读写入口），没有单点故障。添加或移除节点对客户端应用完全透明，无需修改连接配置。
- 实现机制： 节点间通过 Gossip 协议（八卦协议）互相通信，定期交换节点状态、元数据等信息。这就像公司里的同事之间经常闲聊，使得每个人都能掌握公司的最新全局状况，而不需要事事都向CEO汇报。这使得集群能够自我管理和发现。

2. 数据分布与复制 (Replication)

通俗理解：
想象一个巨大的环形货架（一致性哈希环），你的数据（货物）会根据一个分区键（Partition Key）（比如用户ID）计算出一个哈希值（Token），这个值决定了它应该放在环上的哪个位置。环上的不同区段由不同的节点负责管理。
- 数据分布： 你的数据根据计算出的Token值，被存放在环上对应的那个节点上（这个节点叫“协调节点”）。
- 数据复制： 为了保证数据安全和高可用，数据不会只存一份。复制因子（Replication Factor, RF） 决定了数据有多少个副本。系统会按顺时针方向，将数据复制到环上的后续N个节点上（N=RF）。
架构师视角：
- 关键设计： 复制策略（NetworkTopologyStrategy）会考虑机架（Rack） 和数据中心（Data Center） 的物理布局。它会优先将副本分布到不同的机架甚至不同的数据中心，以防止一个机架断电或一个数据中心灾难导致所有数据副本丢失。这是实现跨数据中心容灾的核心机制。
- 你的职责： 作为架构师，你需要根据业务的高可用性要求，来设计分区键和设置复制因子。一个好的分区键能让数据均匀分布，避免“数据热点”；一个合理的RF（通常是3）能在性能和数据安全性之间取得平衡。

3. 可用性 (Availability) vs. 一致性 (Consistency) - CAP定理的权衡

通俗理解（CAP定理）：
在分布式系统中，网络分区（P）无法避免时，你必须在一致性（C）和可用性（A）之间做出选择。
- Cassandra的选择： 它默认优先选择AP（高可用性）。这意味着即使发生网络分区，导致部分节点失联，剩下的节点依然可以对外提供服务（可写可读），但此时不同节点上的数据可能暂时不一致。
架构师视角（可调一致性）：
这是Cassandra最强大的特性之一。它允许你针对每一次读写操作来精细调整你需要的一致性级别（Consistency Level）。
- 最终一致性 (Eventual Consistency)： 默认行为。写入后，可能不会立即在所有副本上看到最新数据，但最终会一致。延迟低，可用性高。
- 强一致性 (Strong Consistency)： 你可以通过配置，要求写入时必须成功写入QUORUM（ majority，即大部分副本，计算公式：RF/2 + 1）的节点，读操作时也必须从QUORUM个节点读取到最新数据。这样就能保证一定能读到最新写入的数据。延迟更高，但数据更一致。
- 你的职责： 作为架构师，你需要根据业务场景决定策略。例如，用户评论可以接受最终一致，但电商下单扣库存可能需要强一致。这是你在架构设计时必须做出的核心决策。

4. 高写入吞吐量 (High Write Throughput)

通俗理解：
传统数据库（如MySQL）在写入数据前，需要先找到数据在磁盘上的确切位置（可能涉及昂贵的随机磁盘I/O），然后再覆盖写入。Cassandra采用了完全不同的思路：
1. 无读写入： 默认情况下，写入数据时不会先去读取旧数据。
2. 内存优先： 所有写入操作都先被记录到一个内存中的结构（MemTable），速度极快。
3. 顺序写盘： 当MemTable满了，它会被整个顺序地、追加写入磁盘文件（SSTable）。顺序写入磁盘的速度比随机写入快几个数量级。
4. 后期合并： 多个SSTable文件会在后台通过压缩（Compaction） 过程进行合并和清理，解决数据重复或过期的问题。
架构师视角：
- 核心技术： LSM树（Log-Structured Merge-Tree） 存储引擎。这是它实现高性能写入的基石。
- 代价： 高写入性能的代价是读操作有时需要合并多个SSTable的数据，可能更慢。但Cassandra通过布隆过滤器（Bloom Filter） 和键缓存（Key Cache） 等机制来优化读性能。

5. 弹性可扩展性 (Elastic Scalability)

通俗理解：
扩展Cassandra集群非常简单：只需要不停机地往集群里添加新机器（节点）即可。新节点加入后，系统会自动地将原有节点上的一部分数据“搬”到新节点上，直到数据在所有节点间重新达到平衡。整个过程对应用程序无感知。性能（吞吐量）几乎随节点数量增加而线性增长。
架构师视角：
- 优势： 线性扩展是Cassandra的核心设计目标，非常适合需要处理不断增长的海量数据的业务场景。
- 操作： 运维上通过nodetool命令工具可以很方便地实现节点的decommission（退役）和assassin（移除），自动化程度很高。

6. CQL (Cassandra Query Language)

通俗理解：
CQL提供了非常类似传统SQL的语法（CREATE TABLE, INSERT, SELECT, UPDATE等），这极大地降低了开发者的学习成本，让他们感觉像是在操作一个熟悉的关系型数据库。
架构师视角（重要提醒！）：
- “形似神不似”： 这是最关键的一点！ CQL在语法上像SQL，但其底层逻辑与关系型数据库（RDBMS）完全不同。
- 设计范式不同： 在Cassandra中，你必须基于查询来设计表结构（Query-Driven Modeling），而不是先设计范式化的表再去写查询。通常需要为不同的查询创建不同的表（数据冗余），这与RDBMS的范式化设计理念背道而驰。
- 不支持： 不支持JOIN、不支持跨分区的事务、外键等关系型数据库的核心特性。UPDATE和INSERT在Cassandra底层几乎是等价的。

总结给你（系统架构师备考者）

Cassandra是一个为大规模、高可用、低延迟写入场景而生的分布式数据库。它的架构设计是一系列精妙权衡的结果：

通过“去中心化”和“复制”来实现【高可用性和容错性】。
通过“可调一致性”让你根据【业务需求】在CAP定理中灵活抉择。
通过“LSM树”和“无读写入”来实现【极高的写入吞吐量】。
通过“一致性哈希”和“对等架构”来实现【线性的弹性扩展】。
通过“CQL”来降低【开发门槛】，但你需要深刻理解其与RDBMS的差异。

在你的架构设计中，如果业务是写密集型（如物联网传感器数据、用户活动日志、消息系统）、需要全球多活、能够接受最终一致性或通过QUORUM实现强一致，那么Cassandra是一个极具竞争力的选择。