参考文档：http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/architecture/architectureDataDistributeAbout_c.html#concept_ds_g43_g3f_fk
在Cassandra中，数据分配和复制是同时进行的。这是因为Cassandra被设计为一个点对点的系统，数据有多个复制，被分发到一组节点上。数据按照表的形式构建以主键进行标识。主键决定了数据存储在那一个节点上面。Cassandra是一个面向行的数据库，行的副本就称其为复制。当数据第一次被写入的时候，就被称为是一个复制。
当你创建集群的时候，你需要指定一下属性：
Virtual nodes（虚拟结点）: 指定数据属于那个物理机器
Partitioner（分区器）: 决定了集群中数据如何分区
Replication strategy（复制策略）: 决定如何进行每个数据行的复制
Snitch（告密者）: 定义了复制策略放置数据复制所采用的拓扑信息
一、一致性哈希
详细说明在Cassandra集群中，一致性哈希机制是如何分发数据的。
采用一致性哈希对数据进行分析是基于主键的。以以下数据为例：
| jim | age: 36 | car: camaro | gender: M |
| carol | age: 37 | car: bmw | gender: F |
| johnny | age: 12 | gender: M | |
| suzy | age: 10 | gender: F | |
Cassandra 通过计算为每个主键分配了一个hash值。
| Primary key | Murmur3 hash value |
|---|---|
| jim | -2245462676723223822 |
| carol | 7723358927203680754 |
| johnny | -6723372854036780875 |
| suzy | 1168604627387940318 |
在集群中的每个节点基于哈希值负责一段连续范围内的数据。
| Node | Murmur3 start range | Murmur3 end range |
|---|---|---|
| A | -9223372036854775808 | -4611686018427387903 |
| B | -4611686018427387904 | -1 |
| C | 0 | 4611686018427387903 |
| D | 4611686018427387904 | 9223372036854775807 |
Cassandra根据主键的哈希值将数据放置在主键所在范围内的节点。
| Node | Start range | End range | Primary key | Hash value |
|---|---|---|---|---|
| A | -9223372036854775808 | -4611686018427387903 | johnny | -6723372854036780875 |
| B | -4611686018427387904 | -1 | jim | -2245462676723223822 |
| C | 0 | 4611686018427387903 | suzy | 1168604627387940318 |
| D | 4611686018427387904 | 9223372036854775807 | carol | 7723358927203680754 |
二、虚拟节点
虚拟节点简化了Cassandra许多工作
•你不需要计算并分配令牌给节点了
•添加和移除节点后不需要再次平衡集群了。当一个节点加入到集群后，他会分担其他节点中一些数据。如果一个节点发生故障时，负载均匀地分布在集群中的其他节点。
•重新恢复一个死亡节点会更快因为它和其他集群中的节点有联系。数据会被逐渐发送到代替节点而不是等到验证阶段的结束。
•提升了异构系统在集群中的使用，你可以指定一个成比例的虚拟节点的数目用来匹配更小或更大的机器。
在1.2版本之前，你需要计算并支配一个单一的token给每一个节点。根据哈希值，每一个token决定了节点的位置和它的数据。（相对于其他分布式设计）尽管在1.2版本之前关于一致性哈希的思想已经允许当添加或移除节点时移动一些数据，但它仍然需要大量的努力。
从1.2版本开始，Cassandra改变了一个节点一个token的设计，一个节点拥有多个token。新的模式就叫做虚拟节点。虚拟节点允许每个节点拥有一大批小分区范围分布在整个集群。虚拟节点也使用一致性哈希分发数据，但它们不需要使用的token 生成和分配。
图片的上半部分展示了一个不使用虚拟节点的集群。在这个模式下，每一个节点分到一个单一的token，代表了它在环上的位置。每个节点存储的数据是通过映射每一行的主键到一个token的值。每个节点还包含集群中的其他节点的一行的副本。例如，E在节点5、6、1中都有。请注意，一个节点拥有一个连续的分区范围。
下半部分是一个采用虚拟节点的环。在一个集群中，虚拟节点随机选择而且不是连续的。每一行的位置由主键的哈希值决定，每一个节点有很多小的分割区域。
三、数据复制
Cassandra 在多个节点上存储的数据的备份，以确保可靠性和容错性。复制策略决定了副本放置在节点方式。
在集群的副本总数被称为复制因子。复制因子为1意味着每一行在一个节点只有一个副本。为2意味着每一行有两个备份，其中每个副本是在不同的节点。所有的副本都同等重要，没有主副之分。一般来说，复制因子不应超过集群中的节点的数目。然而，你可以增加复制因子，然后添加的所需数量的节点。当复制因子超过节点的数目，写请求将被拒绝，但读请求仍然可以只要能满足所需的一致性等级。
两个复制策略是可用的：
• SimpleStrategy: 使用一个单一的数据中心。如果你想要一个以上的数据中心，利用networktopologystrategy。
• NetworkTopologyStrategy: 对于大多数部署情况来说强烈推荐，因为当未来需要扩展时，它更容易的扩展到多个数据中心。
SimpleStrategy
单数据中心使用，SimpleStrategy根据分区器决定第一个副本所在的节点。不考虑拓扑的情况下其他的副本放置在环中顺时针方向的下一个节点。
NetworkTopologyStrategy
当你的集群使用或者计划使用多数据中心时，请使用NetworkTopologyStrategy。这种策略指定了每个数据中心有多少副本。
NetworkTopologyStrategy将在同一个数据中心内副本放置按顺时针方向走直到碰到第一个在另一个机架的节点。NetworkTopologyStrategy试图将副本放置在不同的机架，因为在同一个机架的节点经常会因为电力、冷却或者网络问题同时挂掉。
当决定在每个数据中心应当配置多少个副本时，两个主要的因素需要被考虑：1、去满足本地的读取，不产生跨数据中心的延迟 2、失败的情况。
配置多个数据中心的集群最常见的两种方法：
（1）每个数据中心两个副本：这种配置允许每个备份组出现单节点故障，同时仍然保证本地读取的一致性水平为ONE。
（2）每个数据中心三个副本：这种配置允许每个备份组出现单节点故障，同时保证本地读取的一致性水平为LOCAL_QUORUM。或者每个备份组出现多节点故障，同时保证本地读取的一致性水平为ONE。
非对等的复制组合也是可以的。例如，你可以在每个数据中心存放三个副本用来提供实时应用的需求同时使用一个副本来运行分析。
为keyspace选择副本选项
当你使用NetworkToplogyStrategy，在keyspace创建时，你使用的数据中心的名字应该和集群使用的snitch一致。例如，如果集群使用了PropertyFileSnitch，创建keyspace所使用的数据中心和机架的名字应该在用户定义的cassandra-topologies.properties文件中。如果集群使用 ，创建keyspace应使用的EC2的数据中心和机架。