Cassandra启动过程详解
这里的分析从CassandraDaemon.java文件开始。
一、配置文件storage-config.xml的读取和log4j的配置文件log4j.property的设置。
配置文件的读取和解析都是在org.apache.cassandra.config.DatabaseDescriptor类中完成的,这个类的作用非常简单,就是读取配置文件中各个配置项所定义的值,经过简单的验证,符合条件就将其值赋给DatabaseDescriptor的私有静态常量。值得注意的是关于Keyspace的解析,按照ColumnFamily的配置信息构建成org.apache.cassandra.config.CFMetaData对象,最后把这些所有ColumnFamily放入Keyspace的HashMap对象org.apache.cassandra.config.KSMetaData中,每个Keyspace就是一个Table。这些信息都是作为基本的元信息,可以通过DatabaseDescriptor类直接获取。
二、Keyspace的初始化。
这里主要调用Table.open(tableName)方法创建每个Table的实例。创建Table的实例将完成:1)获取该Table的元信息TableMatedate。2)创建改Table下每个ColumnFamily的存储操作对象ColumnFamilyStore。3)启动定时程序,检查该ColumnFamily的Memtable设置的MemtableFlushAfterMinutes是否已经过期,过期立即写到磁盘。详细过程可参见我前面关于该方法的详细代码跟踪分析。
一个Keyspace对应一个Table,一个Table持有多个ColumnFamilyStore,而一个ColumnFamily对应一个ColumnFamilyStore。Table并没有直接持有ColumnFamily的引用而是持有ColumnFamilyStore,这是因为ColumnFamilyStore类中不仅定义了对ColumnFamily的各种操作而且它还持有ColumnFamily在各种状态下数据对象的引用,所以持有了ColumnFamilyStore就可以操作任何与ColumnFamily相关的数据了。
三、Commitlog日志文件的恢复。
这里调用CmmitLog.recover()方法主要完成这几个操作,发现是否有没有被写到磁盘的数据,恢复这个数据,构建新的日志文件。CommitLog日志文件的恢复策略是,在头文件中发现没有被序列化的最新的ColumnFamilyId,然后取出这个这个被序列化RowMutation对象的起始地址,反序列化成为RowMutation对象,后面的操作和新添一条数据的流程是一样的,如果这个RowMutation对象中的数据被成功写到磁盘中,那么会在CommitLog去掉已经被持久化的ColumnFamilyId。
四、检查数据文件是否需要压缩
调用CompactionManager.instance.checkAllColumnFamilies()检查CF对应的数据文件是否需要压缩。将相似大小的SStable放到一个bucket中,然后调用submitMinorIfNeeded(cfs)。
五、启动存储服务
这是启动过程最重要的一步,需要启动很多服务。具体步骤有:
5.1)创建StorageMetadata
调用方法SystemTable.initMetadata()创建StorageMetadata。元数据只创建一次,如果元数据已经存在,则直接返回。StorageMetadata将包含三个关键信息:本节点的Token、当前generation以及ClusterName。这三个信息被存在StorageService类的属性metadata中(metadata是StorageMetadata类型的对象),以便后面随时调用。
Cassandra