Cassandra维护最终一致性 和存储机制 分区策略

摘自 ：http://asyty.iteye.com/blog/1202072

维护最终一致性

Cassandra 通过4个技术来维护数据的最终一致性，分别为逆熵（Anti-Entropy），读修复（Read Repair），提示移交（Hinted Handoff）和分布式删除。

1)       逆熵

这是一种备份之间的同步机制。节点之间定期互相检查数据对象的一致性，这里采用的检查不一致的方法是 Merkle Tree；

2)       读修复

客户端读取某个对象的时候，触发对该对象的一致性检查：

读取Key A的数据时，系统会读取Key A的所有数据副本，如果发现有不一致，则进行一致性修复。

如果读一致性要求为ONE，会立即返回离客户端最近的一份数据副本。然后会在后台执行Read Repair。这意味着第一次读取到的数据可能不是最新的数据；

如果读一致性要求为QUORUM，则会在读取超过半数的一致性的副本后返回一份副本给客户端，剩余节点的一致性检查和修复则在后台执行；

如果读一致性要求高(ALL)，则只有Read Repair完成后才能返回一致性的一份数据副本给客户端。

可见，该机制有利于减少最终一致的时间窗口。

3)       提示移交

对写操作，如果其中一个目标节点不在线，先将该对象中继到另一个节点上，中继节点等目标节点上线再把对象给它：

Key A按照规则首要写入节点为N1，然后复制到N2。假如N1宕机，如果写入N2能满足ConsistencyLevel要求，则Key A对应的RowMutation将封装一个带hint信息的头部（包含了目标为N1的信息），然后随机写入一个节点N3，此副本不可读。同时正常复制一份数据到N2，此副本可以提供读。如果写N2不满足写一致性要求，则写会失败。 等到N1恢复后，原本应该写入N1的带hint头的信息将重新写回N1。

4)       分布式删除

单机删除非常简单，只需要把数据直接从磁盘上去掉即可，而对于分布式，则不同，分布式删除的难点在于：如果某对象的一个备份节点 A 当前不在线，而其他备份节点删除了该对象，那么等 A 再次上线时，它并不知道该数据已被删除，所以会尝试恢复其他备份节点上的这个对象，这使得删除操作无效。

Cassandra 的解决方案是：本地并不立即删除一个数据对象，而是给该对象标记一个hint，定期对标记了hint的对象进行垃圾回收。在垃圾回收之前，hint一直存在，这使得其他节点可以有机会由其他几个一致性保证机制得到这个hint。

Cassandra 通过将删除操作转化为一个插入操作，巧妙地解决了这个问题。

分区策略

Token，Partitioner

Cassandra中，Token是用来分区数据的关键。每个节点都有一个第一无二的Token，表明该节点分配的数据范围。节点的Token形成一个Token环。例如使用一致性HASH进行分区时，键值对将根据一致性Hash值来判断数据应当属于哪个Token。

 

          图3 Token Ring

 

分区策略的不同，Token的类型和设置原则也有所不同。 Cassandra (0.6版本)本身支持三种分区策略：

RandomPartitioner：随机分区是一种hash分区策略，使用的Token是大整数型(BigInteger)，范围为0~2^127，Cassandra采用了MD5作为hash函数，其结果是128位的整数值(其中一位是符号位，Token取绝对值为结果)。因此极端情况下，一个采用随机分区策略的Cassandra集群的节点可以达到2^127+1个节点。采用随机分区策略的集群无法支持针对Key的范围查询。

OrderPreservingPartitioner：如果要支持针对Key的范围查询，那么可以选择这种有序分区策略。该策略采用的是字符串类型的Token。每个节点的具体选择需要根据Key的情况来确定。如果没有指定InitialToken，则系统会使用一个长度为16的随机字符串作为Token，字符串包含大小写字符和数字。

CollatingOrderPreservingPartitioner：和OrderPreservingPartitioner一样是有序分区策略。只是排序的方式不一样，采用的是字节型Token，支持设置不同语言环境的排序方式，代码中默认是en_US。

分区策略和每个节点的Token(Initial Token)都可以在storage-conf.xml配置文件中设置。

 

bloom-filter, HASH

Bloom Filter是一种空间效率很高的随机数据结构，本质上就是利用一个位数组来表示一个集合，并能判断一个元素是否属于这个集合。Bloom Filter的这种高效是有误差的：在判断一个元素是否属于某个集合时，有可能会把不属于这个集合的元素误认为属于这个集合（false positive）。因此，Bloom Filter不适合那些“零错误”的应用场合，而在能容忍低错误率的场合下，Bloom Filter通过极少的错误换取了存储空间的极大节省。

原理：位数组 + K个独立hash（y）函数。将位数组中hash函数对应的值的位置设为1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是完全正确的。

 

在Cassandra中，每个键值对使用1Byte的位数组来实现bloom-filter。

 

 

图4 Bloom Filter

存储机制

Cassandra的存储机制借鉴了Bigtable的设计，采用Memtable和SSTable的方式。

 

CommitLog

和HBase一样，Cassandra在写数据之前，也需要先记录日志，称之为Commit Log，然后数据才会写入到Column Family对应的MemTable中，且MemTable中的数据是按照key排序好的。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

 

MenTable

MemTable是一种内存结构，当数据量达到块大小时，将批量flush到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。所以我们可以认为Cassandra中只有顺序写操作，没有随机写操作。

 

SSTable

SSTable是Read Only的，且一般情况下，一个CF会对应多个SSTable，当用户检索数据时，Cassandra使用了Bloom Filter，即通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。

为了减少大量SSTable带来的开销，Cassandra会定期进行compaction，简单的说，compaction就是将同一个CF的多个SSTable合并成一个SSTable。在Cassandra中，compaction主要完成的任务是：

1） 垃圾回收： cassandra并不直接删除数据，因此磁盘空间会消耗得越来越多，compaction 会把标记为删除的数据真正删除；

2） 合并SSTable：compaction 将多个 SSTable 合并为一个（合并的文件包括索引文件，数据文件，bloom filter文件），以提高读操作的效率；

3） 生成 MerkleTree：在合并的过程中会生成关于这个 CF 中数据的 MerkleTree，用于与其他存储节点对比以及修复数据。