| 导语 对于 LevelCompact 策略，RocksDB会根据每一层不同的策略计算出CompactScore，根据CompactScore大小来决定那一层将会优先进行Compact，然后选择Level-N 和Level-(N+1）的文件进行Compact。如何计算CompactScore？ 如何选择文件进行Compact？Compact有哪些参数？如何知道RocksDB当前的一个状态？
RocksDB是基于LSM结构的K-V存储引擎，由于数据文件采用Append Only方式写入，而对于过期的数据、重复的数据必然会存在有多份副本，这部分数据通过Compact的方式进行逐步的清理。
那么这里好奇的提出几个问题，由这几个问题引出下文：
RocksDB是如何进行Compact 的？
Compact的时候这些文件是如何进行选择的？
Compact在什么时候、或者什么条件下触发？
对于Compact我们能知道哪些信息？通过TRedis怎么查看这部分信息？
有哪些参数可以控制或者影响到Compact
由于我们的TRedis底层采用RocksDB存储引擎进行持久化，底层数据文件采用分层的方式管理，故这里讨论的Compact 基于Level Compact 。
数据怎么来？我们调用TRedis接口进行写数据时，数据会先写入到内存中的Memtable里边，当Memtable写满后会写入下一个Memtable，Memtable采用Skiplist结构以此保证数据按照Key的字典序进行排序，同时这个Memtable会被后台线程刷到磁盘文件–Level-0，当Level-0文件个数达到一定数量，Compact线程可能会进行Compact，由此产生Level-1，当Level-1文件总大小达到一定大小后， Compact线程可能会进行Compact，由此产生Level-2，…….
RocksDB对每一层的处理规则不太一样，由于Level-0层的数据直接由Memtable dump得到，从而不能保证Level-0层的每个文件Key的范围不能有交集，故对Level-0层的会进行特殊处理，而对于Level-1+层处理规则一样。
Level-0 层的文件在不停的从Memtable 中dump出来，那么何时才会把这些Level-0层的文件合并到Level-1 ？
RocksDB对对每一层进行打分，分数从0~1000000，这个分数的大小决定了进行Compact 的优先级，分数越大，越先进行Compact。
那么这个分数如何计算出来？
如果是Level-0层，会先算出当前有多少个没有进行Compact 的文件个数numfiles, 然后根据这个文件的个数进行判断，
当numfiles<20 时，Score = numfiles/4；当24>numfiles>=20时，Score = 10000；当 numfiles>=24时，Score = 1000000：
