四、副本存储
Cassandra不像HBase是基于HDFS的分布式存储，它的数据是存在每个节点的本地文件系统中。
Cassandra有三种副本配置策略：
1) SimpleStrategy （RackUnawareStrategy）：
副本不考虑机架的因素，按照Token放置在连续下几个节点。如图3所示，假如副本数为3，属于A节点的数据在B.C两个节点中也放置副本。
2) OldNetworkTopologyStrategy （RackAwareStrategy）:
考虑机架的因素，除了基本的数据外，先找一个处于不同数据中心的点放置一个副本，其余N-2个副本放置在同一数据中心的不同机架中。
3) NetworkTopologyStrategy （DatacenterShardStrategy）：
将M个副本放置到其他的数据中心，将N-M-1的副本放置在同一数据中心的不同机架中。
五、网络嗅探
网络嗅探主要用来计算不同host的相对距离，进而告诉Cassandra网络拓扑结构，以便更高效地对用户请求进行路由。主要有三种配置策略：
1) org.apache.cassandra.locator.SimpleSnitch：
将不同host逻辑上的距离（Cassandra Ring）作为他们之间的相对距离。
2) org.apache.cassandra.locator.RackInferringSnitch:
相对距离是由rack和data center决定的，分别对应ip的第3和第2个八位组。即，如果两个节点的ip的前3个八位组相同，则认为它们在同一个rack（同一个rack中不同节点，距离相同）；如果两个节点的ip的前两个八位组相同，则认为它们在同一个数据中心（同一个data center中不同节点，距离相同）。
3) org.apache.cassandra.locator.PropertyFileSnitch:
相对距离是由rack和data center决定的，且它们是在配置文件cassandra-topology.properties中设置的。
六、一致性
在一致性上，Cassandra采用了最终一致性，可以根据具体情况来选择一个最佳的折衷，来满足特定操作的需求。Cassandra可以让用户指定读/插入/删除操作的一致性级别，一致性级别有多种，如图5所示。
图5 Cassandra一致性级别
注：一致性级别是由副本数决定，而不是集群的节点数目决定。
Quorum NRW协议中，只需W + R > N，就可以保证强一致性。一般来说，Quorum中比较典型的NRW为（3,2,2）。
维护最终一致性
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 通过将删除操作转化为一个插入操作，巧妙地解决了这个问题。
七、存储机制
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，用于与其他存储节点对比以及修复数据。
详细存储数据结构参考 http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu2
Cassandra和HBase的一个重要区别是， Cassandra在每个节点是是一个单 Java 进程，而完整的HBase 解决方案却由不同部分组成：有数据库进程本身，它可能会运行在多个模式；一个配置好的 hadoop HDFS 分布式文件系统，以及一个 Zookeeper 系统来协调不同的 HBase 进程。
本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/6278154.html，如需转载请自行联系原作者
