| 導語 對于 LevelCompact 策略，RocksDB會根據(jù)每一層不同的策略計算出CompactScore，根據(jù)CompactScore大小來決定那一層將會優(yōu)先進行Compact，然后選擇Level-N 和Level-(N+1）的文件進行Compact。如何計算CompactScore？ 如何選擇文件進行Compact？Compact有哪些參數(shù)？如何知道RocksDB當前的一個狀態(tài)？
RocksDB是基于LSM結(jié)構(gòu)的K-V存儲引擎，由于數(shù)據(jù)文件采用Append Only方式寫入，而對于過期的數(shù)據(jù)、重復的數(shù)據(jù)必然會存在有多份副本，這部分數(shù)據(jù)通過Compact的方式進行逐步的清理。
那么這里好奇的提出幾個問題，由這幾個問題引出下文：
RocksDB是如何進行Compact 的？
Compact的時候這些文件是如何進行選擇的？
Compact在什么時候、或者什么條件下觸發(fā)？
對于Compact我們能知道哪些信息？通過TRedis怎么查看這部分信息？
有哪些參數(shù)可以控制或者影響到Compact
由于我們的TRedis底層采用RocksDB存儲引擎進行持久化，底層數(shù)據(jù)文件采用分層的方式管理，故這里討論的Compact 基于Level Compact 。
數(shù)據(jù)怎么來？我們調(diào)用TRedis接口進行寫數(shù)據(jù)時，數(shù)據(jù)會先寫入到內(nèi)存中的Memtable里邊，當Memtable寫滿后會寫入下一個Memtable，Memtable采用Skiplist結(jié)構(gòu)以此保證數(shù)據(jù)按照Key的字典序進行排序，同時這個Memtable會被后臺線程刷到磁盤文件–Level-0，當Level-0文件個數(shù)達到一定數(shù)量，Compact線程可能會進行Compact，由此產(chǎn)生Level-1，當Level-1文件總大小達到一定大小后， Compact線程可能會進行Compact，由此產(chǎn)生Level-2，…….
RocksDB對每一層的處理規(guī)則不太一樣，由于Level-0層的數(shù)據(jù)直接由Memtable dump得到，從而不能保證Level-0層的每個文件Key的范圍不能有交集，故對Level-0層的會進行特殊處理，而對于Level-1+層處理規(guī)則一樣。
Level-0 層的文件在不停的從Memtable 中dump出來，那么何時才會把這些Level-0層的文件合并到Level-1 ？
RocksDB對對每一層進行打分，分數(shù)從0~1000000，這個分數(shù)的大小決定了進行Compact 的優(yōu)先級，分數(shù)越大，越先進行Compact。
那么這個分數(shù)如何計算出來？
如果是Level-0層，會先算出當前有多少個沒有進行Compact 的文件個數(shù)numfiles, 然后根據(jù)這個文件的個數(shù)進行判斷，
當numfiles<20 時，Score = numfiles/4；當24>numfiles>=20時，Score = 10000；當 numfiles>=24時，Score = 1000000：
