Cassandra介绍（一）

1.1. 概念 

Apache Cassandra 是高度可扩展的，高性能的分布式 NoSQL 数据库。 Cassandra 旨在处理许
多商品服务器上的大量数据，提供高可用性而无需担心单点故障。
Cassandra 具有能够处理大量数据的分布式架构。 数据放置在具有多个复制因子的不同机器上，
以获得高可用性，而无需担心单点故障。

1.2. 数据模型

Key Space （对应 SQL 数据库中的 database ）
1. 一个 Key Space 中可包含若干个 CF，如同 SQL 数据库中一个 database 可包含多个 table
Key （对应 SQL 数据库中的主键）
2. 在 Cassandra 中，每一行数据记录是以 key/value 的形式存储的，其中 key 是唯一标识。
column （对应 SQL 数据库中的列）
3. Cassandra 中每个 key/value 对中的 value 又称为 column，它是一个三元组，即：name，
value 和 timestamp，其中 name 需要是唯一的。
super column （SQL 数据库不支持）
4. cassandra 允许 key/value 中的 value 是一个 map(key/value_list)，即某个 column 有多个
子列。
Standard Column Family （相对应 SQL 数据库中的 table ）
5. 每个 CF 由一系列 row 组成，每个 row 包含一个 key 以及其对应的若干 column。
Super Column Family （SQL 数据库不支持）
6. 每个 SCF 由一系列 row 组成，每个 row 包含一个 key 以及其对应的若干 super column。

1.3. Cassandra 一致 Hash 和虚拟节点

一致性 Hash （多米诺 down 机）
为每个节点分配一个 token，根据这个 token 值来决定节点在集群中的位置以及这个节点所存储
的数据范围。

虚拟节点（ （down 机 机 多节点托管） ）
由于这种方式会造成数据分布不均的问题，在 Cassandra1.2 以后采用了虚拟节点的思想：不需要
为每个节点分配 token，把圆环分成更多部分，让每个节点负责多个部分的数据，这样一个节点移
除后，它所负责的多个 token 会托管给多个节点处理，这种思想解决了数据分布不均的问题。

 如图所示，上面部分是标准一致性哈希，每个节点负责圆环中连续的一段，如果 Node2 突然
down 掉，Node2 负责的数据托管给 Node1，即 Node1 负责 EFAB 四段，如果 Node1 里面有
很多热点用户产生的数据导致 Node1 已经有点撑不住了，恰巧 B 也是热点用户产生的数据，这样
一来 Node1 可能会接着 down 机，Node1down 机，Node6 还 hold 住吗？
下面部分是虚拟节点实现，每个节点不再负责连续部分，且圆环被分为更多的部分。如果 Node2
突然 down 掉，Node2负责的数据不全是托管给Node1，而是托管给多个节点。而且也保持了一
致性哈希的特点。

1.4. Gossip 协议

Gossip 算法如其名，灵感来自办公室八卦，只要一个人八卦一下，在有限的时间内所有的人都
会知道该八卦的信息，这种方式也与病毒传播类似，因此 Gossip 有众多的别名“闲话算法”、
“疫情传播算法”、“病毒感染算法”、“谣言传播算法”。 Gossip 的特点：在一个有界网络中，
每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一
致。因为 Gossip 不要求节点知道所有其他节点，因此又具有去中心化的特点，节点之间完全对等，不需要任何的中心节点。实际上 Gossip 可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。

Gossip 节点的通信方式及收敛性
Gossip 两个节点（ A 、 B ）之间存在三种通信方式 （ push 、 pull 、 push&pull ）
1. push: A 节点将数据(key,value,version)及对应的版本号推送给 B 节点，B 节点更新 A 中比自
己新的数据。
2. pull：A 仅将数据 key,version 推送给 B，B 将本地比 A 新的数据（Key,value,version）推送
给 A，A 更新本地。
3. push/pull：与 pull 类似，只是多了一步，A 再将本地比 B 新的数据推送给 B，B 更新本地。
如果把两个节点数据同步一次定义为一个周期，则在一个周期内，push 需通信 1 次，pull 需 2 次，
push/pull 则需 3 次，从效果上来讲，push/pull 最好，理论上一个周期内可以使两个节点完全一
致。直观上也感觉，push/pull 的收敛速度是最快的。
gossip 的协议 和 seed list （防止集群分列）
cassandra 使用称为 gossip 的协议来发现加入 C 集群中的其他节点的位置和状态信息。gossip 进
程每秒都在进行，并与至多三个节点交换状态信息。节点交换他们自己和所知道的信息，于是所
有的节点很快就能学习到整个集群中的其他节点的信息。gossip 信息有一个相关的版本号，于是
在一次gossip信息交换中，旧的信息会被新的信息覆盖重写。要阻止分区进行gossip交流，那么
在集群中的所有节点中使用相同的 seed list，种子节点的指定除了启动起 gossip 进程外，没有其
他的目的。种子节点不是一个单点故障，他们在集群操作中也没有其他的特殊目的，除了引导节
点以外

1.5. 数据复制 

Partitioners（ （计算 计算 primary key token 的 的 hash 函数 函数） ）
在 Cassandra 中，table 的每行由唯一的 primarykey 标识，partitioner 实际上为一 hash 函数用
以计算 primary key 的 token。Cassandra 依据这个 token 值在集群中放置对应的行
两种可用的复制策略： 两种可用的复制策略：
SimpleStrategy ： 仅用于单数据中心，
将第一个 replica 放在由 partitioner 确定的节点中，其余的 replicas 放在上述节点顺时针方向的
后续节点中。
NetworkTopologyStrategy ：可用于较复杂的多数据中心。
可以指定在每个数据中心分别存储多少份 replicas。
复制策略在创建 keyspace 时指定，如
CREATE KEYSPACE Excelsior WITH REPLICATION = { 'class' :
'SimpleStrategy','replication_factor' : 3 };
CREATE KEYSPACE Excalibur WITH REPLICATION = {'class' :'NetworkTopologyStrategy',
'dc1' : 3, 'dc2' : 2};

1.6. 数据 写请求和协调者

协调者 协调者(coordinator)
协调者(coordinator)将 write 请求发送到拥有对应 row 的所有 replica 节点，只要节点可用便获取
并执行写请求。写一致性级别(write consistency level)确定要有多少个 replica 节点必须返回成功
的确认信息。成功意味着数据被正确写入了 commit log 和 memtable。

1.7. 数据读请求和后台修复

1. 协调者首先与一致性级别确定的所有 replica 联系，被联系的节点返回请求的数据。
2. 若多个节点被联系，则来自各 replica 的 row 会在内存中作比较，若不一致，则协调者使用含
最新数据的 replica 向 client 返回结果。那么比较操作过程中只需要传递时间戳就可以,因为要
比较的只是哪个副本数据是最新的。
3. 协调者在后台联系和比较来自其余拥有对应 row 的 replica 的数据，若不一致，会向过时的
replica 发写请求用最新的数据进行更新 read repair。