想象圆桌骑士会议：这里没有国王、没有发号施令的皇帝。所有骑士围成一个大圆环，每个人地位绝对平等。哪怕其中几个骑士睡着或负伤了，其他骑士照样能把全国大事商量得妥妥当当！
皇帝与随从模式： 只有 Master（主节点）负责写，Slave 只能默默复制读。
💥 致命单点风险： 一旦 Master 宕机或网络分区，全系统写不可用，必须选主（Failover），期间系统抖动！
💥 写瓶颈死穴： 写入请求全砸给皇帝一人，无法横向平摊写入压力。
圆桌自治模式： 所有节点平等对等，首尾相接组成一个一致性哈希 Token 环。
✨ 零单点故障： 客户端连上哪台，哪台就是当次操作的“协调者（Coordinator）”。
✨ 写入横向无限扩张： 节点越多，整个集群的写入 QPS 呈线性直接翻倍！
✨ 高可用容灾： 副本多机房分散，哪怕死掉一两个节点，数据依然在其他副本完好无损。
在传统数据库里，写入要跑到磁盘到处找空位“随机改写”；而 Cassandra 坚决不改原文件，所有新数据先进内存 Memtable，顺手往磁盘记一笔连续的日志 CommitLog，然后直接告诉客户端“写好了”！
集群里的节点之间每秒都在互相传递“八卦传闻”。谁的网线被拔了、谁重新上线了，短短几百毫秒内全网几百台机器就能达成共识，完全不需要中心调度服务器。
你可以自由选择业务的一致性级别：追求极致速度可以设置 QUORUM 或 ONE；利用数学公式 $R + W > N$（读节点数+写节点数>总副本数），就能在最终一致性系统上保证强一致性！
很多数据库做跨大洲多活需要昂贵的插件和复杂的专线同步；Cassandra 出生那一天就原生支持多机房意识（Rack / DC Aware），一份数据在北京，两份数据在法兰克福，网络切断后自动断点续传（Hinted Handoff）。
下方是 4 个对等节点组成的 Cassandra Token 环。你可以点击任意圆球模拟拔掉网线（故障），或者点击“发送一次读写操作”观察协调者与法定人数（Quorum）：
Cassandra 最早由 Facebook 工程师为了解决收件箱海量搜索而设计，完美融合了 Amazon Dynamo 的去中心化无主环 与 Google BigTable 的列族与 LSM-Tree 存储，后来开源贡献给了 Apache 基金会。
苹果公司运行着数以万计节点的 Cassandra，用来支撑数亿用户的 iCloud 同步；Netflix 用它存储全人类所有观众的播放进度和点播历史，每日承受千亿次调用而稳如泰山。
Cassandra 用 Java 编写，因而在极高吞吐下常受 JVM GC 卡顿困扰。这也正是我们前一期介绍的 ScyllaDB 用 C++ 重写它、全面兼容其 CQL 协议并开创新时代的缘起！