Cassandra数据库

教程导读：Cassandra 数据库

一句话定位：Cassandra 是为超大规模写入与多活容灾设计的宽列数据库。本教程采用对比驱动主调：在 MongoDB、HBase、PostgreSQL 对照中理解何时选 AP 路线、何时退回关系库。

这门课解决什么问题

2006 年 Facebook Inbox Search 在 MySQL 双写上频繁出现「消息已发却搜不到」——网络分区时主库成功、索引失败。Avinash Lakshman 与 Prashant Malik 据此设计 Cassandra：无主复制、可调一致性、写入吞吐随节点线性增长。Netflix、Apple、Uber 用它承载会话、轨迹与指标；但若把 Cassandra 当「分布式 MySQL」用 JOIN 和 ad-hoc 查询，会迅速撞墙。本教程帮你建立「查询驱动建模 + CL 选型」坐标系。

适合谁读

• 负责 IoT、日志、全球多活会话的后端与数据架构师
• 已用 MongoDB/HBase，想理解 Cassandra 与它们的 CAP 差异
• 运维需要读懂 nodetool repair、Compaction 与 GC 日志的 DBA/SRE

学习路线

Cassandra 在 NoSQL 谱系中的位置

怎么用本教程

每章先读支柱页对比表，再进各节。SOURCE 中的 Facebook Inbox 双写失败、CQL 1.2 默认接口、NetworkTopologyStrategy 跨 Rack 副本、memtable_heap_space_in_mb 与 G1GC 等事实均保留在对应节内。与 798 时序库 对比驱动风一致，但本章聚焦宽列 AP 而非 metric-tags-time。

⚠️ 常见误区：在 R=3 集群用 CL=ALL——任一节点抖动即全集群写阻塞。

💡 关键直觉：Cassandra 优化的是「已知查询路径上的海量写入」；先画访问模式，再建表。

前置知识

• 了解 CAP 与 NoSQL 基本分类
• 会写简单 SQL；无需事先跑过集群
• 接触过 Linux 部署或 Docker 更佳

章节概览

1. 概述与 CAP — Facebook 起源、AP 定位、去中心化与线性扩展
2. 分布式架构 — Gossip、复制与 CL、Memtable/SSTable/Compaction
3. 数据建模与 CQL — 键空间、主键设计、查询驱动反模式
4. 集群运维 — Snitch、扩缩容、repair、快照与 RBAC
5. 性能与选型 — JVM/G1、批写与缓存、Mongo/HBase/PostgreSQL 决策表

一次真实的读写旅程

先看一条 CQL 写入语句在集群中的完整路径，这是理解后续所有章节的最小框架：

-- 客户端任意连接一个节点（9042 端口），该节点成为本次请求的 Coordinator
CONSISTENCY QUORUM;
INSERT INTO sensor_data (device_id, reading_ts, temp)
VALUES ('dev-2210', toTimestamp(now()), 23.8);
​

Coordinator 用 Murmur3 对 device_id 哈希得到 token，沿 Token Ring 顺时针定位前 RF 个副本节点，把 Mutation 并行下发；收到 ⌊RF/2⌋+1 个 ACK 后即向客户端返回成功。全程没有中心元数据服务参与路由，这就是第2章 Gossip 与 Token Ring 要展开的内容。

# 在任一节点上验证你的理解：查看环布局与节点状态
nodetool status
# Datacenter: dc-east
# ===================
# UN  10.0.1.10  256 bytes  100.00%  ...
# UN  10.0.1.11  256 bytes  100.00%  ...
​

故障演练：协调节点宕机

假设 RF=3、客户端用 CL=QUORUM（需 2 个 ACK）。写入时如果协调节点收到 1 个 ACK 后超时，客户端得到 WriteTimeoutException——但数据可能已经写入 1 个副本。这正是本教程反复强调「客户端必须幂等重试」的原因。

术语速查（首见即懂）

延伸阅读路径

本教程与 798 时序库 教程同属对比驱动风格：那里讨论 metric-tags-time 模型，这里聚焦宽列 AP 与 CQL。想深入某条线的读者，可按下表跳读：