Cassandra1.1.0中Compaction部分源代码解析——准备篇

Cassandra目前已经发布了1.1.0，更新速度也还算可以，但是Cassandra屡屡被抛弃的事实，让我们不仅对它的前景表示担忧，好了不说废话了进入正题。写这部分动机一是对自己这段时间工作的总结，另外一个就是Cassandra使用者较少，很多的资料都是0.7以前的，希望这部分的内容能给大家带来帮助，当然更渴望大神给予指点。Ok，let’s go！

compaction是神马，为神马进行compaction

compaction翻译我有点乏力，姑且就叫做合并吧。其实意思就是将几个数据块合并成一个数据块，去掉不同数据块中重复的部分。compaction是在当前NoSQL的系统中都存在的一种机制，因为NoSQL系统都是没有更新和删除的操作，所有的这些操作都定位为写操作，因此数据中就会存在新、老和待删除的数据，因此Compaction的存在就合情合理了。

Cassandra中的compaction机制

Cassandra目前有两种类型的Compaction机制SizeTieredCompactionStrategy和LeveledCompactionStrategy，Cassandra1.0之前的使用的都是SizeTieredCompactionStrategy，1.0之后推出了LeveledCompactionStrategy，这是模仿LevelDB的一种实现。目前默认还是使用SizeTieredCompactionStrategy。

这两种Compaction机制的原理有不少的博文都讲过，我就不多说废话，简单的介绍一下。

1.1.0中SizeTieredCompactionStrategy具体实现方式是，将所有cfs的sstable按大小进行分组，将大小相似的sstable归为一组，这样就形成n个组（n>=1），再从这n个组中获取平均大小最小的一个组形成一个task进行compaction的操作。每组的大小必须在（4,32]的范围内，数量过多的组将进行截断。

LeveledCompactionStrategy具体的实现方式是，从最高的level上开始扫描是否需要进行compaction，如果有将该层的sstable形成一个task。优先对高层sstable优先进行compaction的好处是，能有效减少底层到高层compaction时合并的sstable的数目。有个特殊的地方是，level0层向level1层compaction的时候一个task最多包含32个sstable。

启动Compaction机制的入口

写这部分的目的，可能是个人习惯原因，总是有这样一种感觉，不知道事情怎么发生的就看着不踏实。

启动Compaction是在ColumnFamilyStore中，因为每一个cfs对应一种compaction机制。具体代码如下：

this.compactionStrategy = metadata.createCompactionStrategyInstance(this); try { //默认使用SizeTieredCompactionStrategy Constructor<? extends AbstractCompactionStrategy> constructor = compactionStrategyClass.getConstructor(new Class[] { ColumnFamilyStore.class, Map.class // options }); //调用相关CompactionStrategy的构造函数进行初始化 return constructor.newInstance(cfs, compactionStrategyOptions); }

能够提交compaction任务（也就是能够调用submitBackground函数）的地方

一共有3个这样的地方：

（1）submitBackground自身，这是一个递归函数在执行一个task结束后会调用自己，这样做能够保证已经加入的sstable最终都能被合理的compaction。

（2）ColumnFamilyStore的addSSTable（）函数中。

（3）ColumnFamilyStore中的replaceFlushed()函数，这个就是Memtable从内存刷出到磁盘过程中需要调用的一个函数，很明显当有新的sstable加入时，需要启动compaction的过程。

准备介绍完毕，后边开始源代码的解析。