针对0.6系列版本
cassandra总体的设计感觉偏向于不需要人工介入的大规模集群，有个几百台上千台，局部有些抖动不会影响整体的服务；如果集群规模较小，几十台的规模，而且在线上run，它提供的很多操作都相当有风险，而且p2p的通信也感觉过重了。
几个概念
1. DHT（Distributed Hash Table）
对key做hash，把数据分布到整个集群。每台机器负责一个range的key的存储，整个集群的range构成一个闭环。
2. Replication
每个key的数据会在集群中另外某台机器上进行备份。
3. Read Repair
对某个key的read会同时在所有replication机器上进行（一台做数据read，其他的都做摘要read），然后在一台机器进行比较，如果不同就发起一次data repair操作，把该key的几份数据copy进行同步。
4. Hinted Handoff
某个key对某台机器A写入失败，会在该key的一台replication机器B上记录。等失败机器A重启后，B会检测到，然后把失败key的数据同步给A机器。
5. P2P
集群使用p2p通信（Gossip协议），系统没有单点。
6. Storage（参考Bigtable数据存储模型）
Commitlog：硬盘log文件，每次write操作都会先在此持久化，再进到内存
Memtable：内存hashmap，write操作数据先存放这里，到一定大小后，flush进入硬盘，并删除Commitlog中相应记录
SSTable：memtable的硬盘文件，经过排序，包括索引文件和数据文件两部分。
Compaction：多个sstable进行合并，删除冗余信息
分布式存储
cassandra把所有机器组成一个环状结构，每个机器负责一个token。read/write操作过来后，会根据key算出具体负责的机器，然后把请求转发过去。
动态添加一台机器，叫做Bootstrap，只会影响一个token两边的两台机器，对整个集群不会有太大影响。 但实际上这个不具有太强的操作性，因为要么机器成倍增，要么不增，否则数据会不平衡。
cassandra内部集群管理通信和活跃检测是基于p2p的，那一块代码相当繁琐，感觉是为了实现算法而写的代码；我改过一个基于zookeeper的版本，提前在zookeeper里设置好数据环状结构，哪台机器负责哪个token，心跳检测也由zookeeper提供，比较简洁，而且跟其他模块的借口保持不变。
数据一致性
cassandra有个NRW的概念，N表示备份个数，R表示读多少份copy才返回给用户，W表示写多少份copy后才返回给用户。通过调整这几个参数，可以达到不同的目标。
cassandra还有个技术叫read-repair，同一个key会从多个copy机器中同时读（Digest query），然后进行对比，如果结果不一致就说明有copy的数据有问题；这时就做一次查询，把这个key的所有copy数据都拉到一起来，做一次merge，生成最新的完整的数据，然后分别与各个copy的数据做diff，把diff结果作为更新操作发给相应的copy机器。不难看出，read-repair还是很费性能的，所以在0.6后来的版本中，添加了一个配置项，以一定的概率去做DigestQuery。
如果有机器挂掉，cassandra用HintedHandoff先把到这台机器的更新发给其他机器，等这台机器恢复了后，handoff的机器再把收集的更新消息回送给他。
cassandra还有一招大杀器，anti-entropy，在节点之间做数据同步，看过代码，但从来没试过，谁敢在线上做这种操作啊。
