針對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，在節點之間做數據同步，看過代碼，但從來沒試過，誰敢在線上做這種操作啊。
