1. http://blog.sina.com.cn/s/blog_672e41a00100judt.html
2. http://blog.csdn.net/firecoder/article/details/5865559
主要分析一下它的在收到读写请求的时候的大致逻辑：
cassandra很大程度上简化了写操作，把复杂留给了读。下面各自分析一下（为了突出重点，忽略掉hint等细节工作，也忽略掉consistanyLevel的相关操作）：
1. 在收到一个写的消息后，先通过hash计算是不是本机的key，如果不是，转发请求；否则，通过线程池新起一个线程，执行写入操作，写入到memtable；然后考察memtable是否到达threshold，如果是，将memtable放入待flush队列，异步执行flush，生成bloomfileter，index和data3个文件，每次memtable生成单独sstable，也就是说一个key的不同列可能分布在不同的sstable中。
2. 在收到一个读请求后，先通过hash计算是不是本机的key，如果不是，转发请求；否则，先读取memtable，包括待flush的memtable，然后一一读取所有的sstable（可能在读取初期因为bloomfilter就返回了），然后merge所有的结果，返回。读取sstable的时候，先取得key对应的index信息，取出数据，再根据column的index信息，取出对应的column（get_slice没有一步）；取得key对应的index信息的时候，先查cache，如果没有，查sstable的indexsummary（在内存中），通过二分查找，找到key对应的cache的块（现在128个key），从filesystem读入内容，找到key对应的index，返回data文件的位置。
以下简单画了几个示意图：
