参考文档：http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/architecture/architecturePartitionerAbout_c.html#concept_ds_dwv_npf_fk
一个分区器决定了数据是怎样分布在集群中的节点上的。通常，一个分区器就是一个hash函数去计算每一行键值的hash值——token。每一行数据通过一个键值唯一标识并且在集群中按token分部。
Murmur3Partitioner 和 RandomPartitioner都使用token去帮助分配相同部分的数据在每个节点上并均匀的分配所有表中的数据到环上或其他分组（例如keyspace）。即使table使用了不同的行键值，例如用户名或者时间戳。甚至于，集群的读请求和写请求同样也是平均的分布并且负载平衡的，因为平均每部分的Hash范围都接收到相等数目的行。
Cassandra提供了以下分区器：
•Murmur3Partitioner (默认地): 在集群中均匀地分布数据基于 MurmurHash 哈希值
•RandomPartitioner: 在集群中均匀地分布数据基于 md5 值
•ByteOrderedPartitioner:通过key的字节来保持数据词汇的有序分布
对于新的Cassandra 集群，Murmur3Partitioner 是默认的分区策略，在几乎所有情况下都是正确的选择。
在 cassandra.yaml文件中指定分区器：
•Murmur3Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
•RandomPartitioner: org.apache.cassandra.dht.RandomPartitioner
•ByteOrderedPartitioner: org.apache.cassandra.dht.ByteOrderedPartitioner
提示：如果使用虚拟节点，你不需要计算节点的token。如果没有使用虚拟节点，在cassandra.yaml文件中你必须计算token并分配给 initial_token参数。
Murmur3Partitioner
相比于原来默认地分区器RandomPartitioner，Murmur3Partitioner哈希更快而且性能更好。
对于新的集群，你完全可以只使用Murmur3Partitioner。你不能改变已有节点的分区器。如果你使用1.2版本的cassandra.yaml，你需要确认修改分区器设置以匹配之前的分区器。
Murmur3Partitioner使用MurmurHash函数。MurmurHash哈希函数为每一个行键值创建了64比特的哈希值。哈希数值的范围从-263 到2+63.
当使用Murmur3Partitioner的时候，你可以在CQL 3 查询中使用token function为所有行分页。
RandomPartitioner
Cassandra 1.2之前的默认分页器。
虽然不再是默认分页器了，你仍然可以在Cassandra 1.2中使用RandomPartitioner，甚至在使用虚拟节点时使用RandomPartitioner。然而，如果你不使用虚拟节点，你必须计算token，就像在 Generating tokens中描述的那样。RandomPartition分发数据使用MD5哈希函数计算行键值。数值范围从0到2127 -1。当使用RandomPartitioner的时候，你可以在CQL 3 查询中使用token function为所有行分页。
ByteOrderedPartitioner
用来进行有序的分区。
Cassandra 提供ByteOrderedPartitioner 用来进行有序的分区。这个分区器按key的字节值来进行排序。你可以通过查看行键值的真实数值，采用16进制表示key的首字母来计算token。例如，如果你想让行按字母顺序排列，你可以指定一个tokenA使用16进制的41表示。
使用有序分区器允许按主键有序遍历。这意味着你可以遍历每一行就好像使用一个游标通过一个传统的数据库索引。例如，如果你的程序使用用户名作为行键值，你可以遍历用户（姓名在 Jake和Joe之间）。对于随即分区器来说这种方式的查询是做不到的，因为键值按照md5的顺序存储，而不是顺序的。
尽管对于有序分区器来说拥有这种能力听起来是一个非常棒的特性，但通过table indexes也能实现同样的功能。
因为以下原因，不建议使用有序分区器：
1、困难的负载平衡
为了保持集群的负载平衡，需要更多的管理开销。一个顺序的分区器需要管理员经常性的计算 partition ranges根据行键值的分布估计。在实践中，但数据加载后需要经常性的改变节点的token去适应实际数据的分布。
2、顺序写导致热点
如果你的程序写入或者更新一块数据包含很多按顺序排列的行的时候，它们不会分布在集群上，会分布同一节点上。当系统处理和时间相关的数据的时候这是一个常见的问题。
3、多表时负载不平衡
如果你的应用程序用到多个表，这些表有不同的行键值和不同的数据分布。在同一个集群中，对于一张表一个有序的分区对于另一个表可能会导致热点和不均匀分布。