本文已迁移到我的新博客地址：blog.favorstack.io 欢迎访问~
本文主要翻译自Datastax公司的在线文档，Cassandra版本为2.1。由于水平有限，翻译不当之处还请大家指正。
在Cassandra中数据分发和复制是同步的。数据由表组织，并且由主键唯一标识，主键确定数据在哪个节点中存储。副本即行的拷贝，数据第一次写入，也称之为一个副本。
影响副本的因素包括：
- 虚拟节点：将数据所有权分配给物理机器
- 分区器：将数据在集群中分区存放
- 复制策略：确定每行数据的副本
- Snitch：定义复制策略用来放置副本的拓扑信息
一致性哈希
当添加或移除节点时，一致性哈希确保最小化重组分布在集群中的数据。一致性哈希分区数据基于分区键。（分区键和主键的释义，请参考Cassandra2.0&2.1版的CQL文档中的数据模型示例）。
例如，有如下数据：
| name | age | car | gender |
| jim | 36 | camaro | M |
| carol | 37 | F | |
| johnny | 12 | M | |
| suzy | 10 | F |
Cassandra为每一个分区键分配一个哈希值：
| 分区键 | Murmur3哈希值 |
| jim | -2245462676723223822 |
| carol | 7723358927203680754 |
| johnny | -6723372854036780875 |
| suzy | 1168604627387940318 |
集群中每个节点都会负责一个基于该哈希值的数据范围：
Cassandra根据分区键的值和节点负责的范围来放置数据。比如，在一个4个节点的集群中，该示例的数据将按如下分布：
| Node | Start range | End range | Partition key | Hash value |
| A | -9223372036854775808 | -4611686018427387903 | johnny | -6723372854036780875 |
| B | -4611686018427387904 | -1 | jim | -2245462676723223822 |
| C | 4611686018427387903 | suzy | 1168604627387940318 | |
| D | 4611686018427387904 | 9223372036854775807 | carol | 7723358927203680754 |
虚拟节点
在Cassandra中虚拟节点能简化许多任务：
- 不再需要为每一个节点计算和分配token
- 新增或移除节点时，不再需要重新均衡集群。当一个节点加入集群后，它会承担起集群中其他节点的一部分数据。如果一个节点 失败了，负载将会均匀地传播到集群中其他节点上。
- 重建一个死亡的节点是很快的，因为它涉及到集群中的每一个节点
- 提高集群中异构机群的利用率。你可以在较小或较大的机器中按比例分配vnodes
数据在集群中是如何分布的（虚拟节点构成）
在1.2版本之前，你需要为集群中的每一个节点计算并分配单独的token，每个token决定了节点在环中的位置以及所要承担的部分数据。从1.2版本开始，Cassandra允许一个节点有多个token，新的模式被称为虚拟节点（vnode）。Vnodes允许每个节点拥有大量分布在集群中的小分区范围的数据。Vnodes也使用一致性哈希来分发数据，但是不需要生成和分配token。
图片的上部分展示了一个没有虚拟节点的集群，该模型中每个节点都分配了一个token用于负责环中的一个位置。每个节点存储的数据由分区键到token值的映射来确定，该值在前一个节点到该节点的范围内。每个节点还包含集群中其他节点上的每行的拷贝。例如：范围E复制到了节点5,6和1上。需要注意的是，节点在环上拥有一个明确的连续分区范围。
图片的下部分展示了一个由虚拟节点构成的环，在该集群中，虚拟节点是随机选取的，并且是不连续的。行的存放是由每个节点中许多小的分区范围中的分区键的哈希决定的。
数据副本
Cassandra将数据存储于多个节点上以确保可靠性和容错性。副本放置策略决定了哪些节点用于存放数据。集群中所有副本的总和称为副本因子。副本因子1代表每行数据只有一份拷贝并且只存在于一个节点上；副本因子为2代表每行数据有两份拷贝，并且分别存储于不同的节点上。所有的副本的重要性都是相同的，没有主副之分。原则上，副本因子不能超过集群中节点的数量，但是，你可以先增加副本因子，然后添加所需的节点数。
有两个可用的副本放置策略：
- SimpleStrategy：只用于单数据中心。如果你想要一个以上的数据中心，使用NetworkTopologyStrategy。
- NetworkTopologyStrategy：强烈建议大多数部署采用该策略。因为在将来需要扩展的时候很容易扩展到多个数据中心。
SimpleStrategy
只用于单数据中心。SimpleStrategy使用分区器来确定第一份副本的位置。其他副本顺时针放置在环上的下一个节点，并不考虑拓扑结构（机架或数据中心的位置）。
NetworkTopologyStrategy
如果你的集群部署（或计划部署）在多个数据中心，使用NetworkTopologyStrategy。该策略指定每个数据中心存放多少个副本。
NetworkTopologyStrategy在同一个数据中心中按顺时针存放副本，直到遇到另一个机架上的第一个节点。
NetworkTopologyStrategy试图将副本存放到不同的机架上，因为同一个机架上的节点（或相同的物理组）通常会由于电源，散热 或网络问题等一起宕掉。
当确定每个数据中心要配置几个副本后，两个主要考虑的因素是（1）能够满足本地读，而不会产生跨数据中心的延迟。（2）故 障场景。两种常用的多数据中心集群配置方式如下：
- 每个数据中心2个副本：该配置容忍每个副本组的单节点故障，并且在一致性级别为ONE的情况下仍然允许本地读。
- 每个数据中心3个副本：该配置在强一致性级别为LOCAL_QUORUM时容忍每个副本组单节点故障，或一致性级别为ONE时容 忍每个数据中心多节点故障。
非对称副本组也是可以的。比如，你可以在一个数据中心放置3个副本用于提供应用的实时请求，而在任意其他地方只放置1个副本用于运行分析统计。
选择keyspace的副本选项
要设置副本副本策略，请参考CREATE KEYSPACE命令语法。
使用NetworkTopologyStrategy，当创建keyspace时，要使用为Snitch定义的数据中心的名字。为了将副本放置到正确的位置，Cassandra需要一个包含为Snitch定义的数据中心名字的keyspace定义。例如，假设集群使用PropertyFileSnitch，那么使用位于cassandra-topologies.properties配置文件中的用户自定义数据中心和机架名称来创建keyspace；如果集群使用Ec2Snitch，则使用EC2的数据中心和机架名称来创建；如果集群使用GoogleCloudSnitch，则使用GoogleCloud的数据中心和机架名称来创建。
注：文中引用图片均来源于DataStax文档。
原文地址:http://docs.datastax.com/en/cassandra/2.1/cassandra/architecture/architectureDataDistributeAbout_c.html