cassandra源码分析

from:
1.[url]http://blog.sina.com.cn/s/blog_672e41a00100judt.html[/url]
2. [url]http://blog.csdn.net/firecoder/article/details/5865559[/url]

主要分析一下它的在收到读写请求的时候的大致逻辑：

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文件的位置。

以下简单画了几个示意图：

[img]http://dl.iteye.com/upload/attachment/0069/3278/7604e7f4-80d6-3763-8b85-2634aa95b6f1.jpg[/img]

[img]http://dl.iteye.com/upload/attachment/0069/3280/f1645838-21f0-3b41-b686-2a052ad58b07.jpg[/img]

[img]http://dl.iteye.com/upload/attachment/0069/3282/6b251e3e-62c9-32f9-8d1e-c61f4494316f.jpg[/img]