案例库 · 软件与 IT · 技术决策 · 2008–2010
Cassandra让Facebook的Inbox Search在故障和数据中心分裂时仍可写入
类似Bigtable的列模型加上Dynamo风格的法定人数机制，让Cassandra每天吸收数十亿次写入，且没有单点故障。
那一手
Facebook的Inbox Search需要处理每天数十亿次的写入，并随着数亿用户扩展，服务分布于多个地理数据中心。在组件频繁故障的基础设施上，存储层必须将故障视为常态而非例外。
Cassandra结合了成熟的技术：Dynamo风格的分区、基于法定人数的复制和用于成员管理与故障检测的gossip协议，以及类似Bigtable的列族模型。没有主节点，也没有单点故障，因此读写操作在故障期间仍能继续工作，数据跨数据中心复制，保持搜索低延迟。
Inbox Search于2008年6月在Cassandra上上线，服务约1亿用户，到LADIS论文撰写时用户数已超过2.5亿；Cassandra还成为Facebook其他多个服务的后端。
为什么管用
- 无主节点意味着任何节点都能服务读写
- 法定人数复制在节点故障时保持可用性
- 基于gossip的成员管理可扩展到数百个节点
- 列族模型适合高吞吐量的半结构化数据
值了多少将组件故障视为常态，而非例外聪明
可以搬走什么
当产品必须永不停止写入时，为故障设计存储：分散权威，跨数据中心复制，让一致性可调而非绝对。
后来呢
Facebook将Cassandra贡献给Apache基金会，该项目网站将其描述为开源NoSQL数据库，被数千家公司信任，用于线性扩展和经过验证的容错性，运行在商品硬件上，Netflix和Bloomberg是其中的用户。
资料来源
发现哪里写错了？告诉我们。