Graphene 源码阅读 ~ 数据库篇 ~ 区块数据管理
在 bitshares 中除了对象数据需要落盘之外, 网络上接收到的区块数据也是需要落盘的, 区块数据的管理依赖的就是 chain::block_database 模块.
这个模块听起来好像很复杂 - 毕竟管理着区块数据的落盘与加载, 但实际上非常简单. 它维护了两个文件流: _blocks 存储具体区块数据, _block_num_to_pos 则是索引数据. 当我们知道了区块 id 或者区块号时, 就可以从 _block_num_to_pos 查询出此区块在 _blocks 中的偏移和大小, 进而从 _blocks 中取出整个块数据.
区块数据在内存中由 chain::signed_block 类型表示, 但是与对象在内存中会挂到红黑树上不同, 区块数据从其他节点收到并 apply 完后就会序列化到磁盘并在内存中释放.
读写 _blocks 文件流时会涉及到区块数据的序列化与反序列化, 这里依赖的也是 对象序列化 中介绍的 fc::raw::pack/fc::raw::unpack, 不再敖述.
而读写 _block_num_to_pos 流时关于区块索引的序列化反序列化就简单了, 它没有使用 fc::raw::pack/fc::raw::unpack, 而是简单粗暴的强转成字符序列:
// 代码 6.1
78 void block_database::store( const block_id_type& _id, const signed_block& b )
79 {
80 block_id_type id = _id;
81 if( id == block_id_type() )
82 {
83 id = b.id();
84 elog( "id argument of block_database::store() was not initialized for block ${id}", ("id", id) );
85 }
86 _block_num_to_pos.seekp( sizeof( index_entry ) * int64_t(block_header::num_from_id(id)) );
87 index_entry e;
88 _blocks.seekp( 0, _blocks.end );
89 auto vec = fc::raw::pack( b );
90 e.block_pos = _blocks.tellp();
91 e.block_size = vec.size();
92 e.block_id = id;
93 _blocks.write( vec.data(), vec.size() );
94 _block_num_to_pos.write( (char*)&e, sizeof(e) );
95 }
反序列过程实际上面说过了, 就是拿区块 id 或者区块号从 _block_num_to_pos 查询出此区块在 _blocks 中的偏移和大小, 然后从 _blocks 中取出整个块数据:
// 代码 6.2
184 index_entry e;
185 int64_t index_pos = sizeof(e) * int64_t(block_num);
186 _block_num_to_pos.seekg( 0, _block_num_to_pos.end );
187 if ( _block_num_to_pos.tellg() <= index_pos )
188 return {};
189
190 _block_num_to_pos.seekg( index_pos, _block_num_to_pos.beg );
191 _block_num_to_pos.read( (char*)&e, sizeof(e) );
192
193 vector<char> data( e.block_size );
194 _blocks.seekg( e.block_pos );
195 _blocks.read( data.data(), e.block_size );
196 auto result = fc::raw::unpack<signed_block>(data);
197 FC_ASSERT( result.id() == e.block_id );
198 return result;
如果说 db::object_database 是管理对象数据, chain::block_database 管理区块数据, 那么 chain::database 就是管理 db::object_database 和 chain::block_database 了. 从结构上来讲 chain::database 的内容应该单独放在一篇文章里, 但是由于 block_database 模块比较简单, 篇幅太少, 而 chain::database 的内容有比较多, 估计下一篇一篇介绍不完, 所以这里就暂且先把 chain::database 的初始化部分挪到这里来. 也能让我们先对 chain::database 有个大概的认识.
chain::database 的初始化涉及到两个过程, 一个是节点实例被构造时, 同时也会构造 chain::database 实例, 而在 chain::database 构造时就会执行我们前面章节提到过的 initialize_indexes(), add_index<>() 等过程. 对应下面这条链路:
node = new app::application() => new detail::application_impl(this) => _chain_db(std::make_shared<chain::database>()
chain::database() => initialize_indexes()
=> add_index<>()
其次就是在节点 startup 时, 会调用 chain::database::open() 方法, 这里面包含了 chain::database 初始化阶段的主要工作内容.
首先, 读取 witness_node_data_dir/blockchain/db_version 文件, 比较一下数据库版本和当前运行的版本的程序的数据库版本是否一致, 如果版本不一致或者这个文件不存在, 就会先清空对象库, 然后写入当前的版本号.
// 代码 6.3
143 bool wipe_object_db = false;
144 if( !fc::exists( data_dir / "db_version" ) )
145 wipe_object_db = true;
146 else
147 {
148 std::string version_string;
149 fc::read_file_contents( data_dir / "db_version", version_string );
150 wipe_object_db = ( version_string != db_version );
151 }
152 if( wipe_object_db ) {
153 ilog("Wiping object_database due to missing or wrong version");
154 object_database::wipe( data_dir );
155 std::ofstream version_file( (data_dir / "db_version").generic_string().c_str(),
156 std::ios::out | std::ios::binary | std::ios::trunc );
157 version_file.write( db_version.c_str(), db_version.size() );
158 version_file.close();
159 }
然后就是调用 object_database 和 block_database 的 open() 方法, 到这里我们看到了 chain::database 确实是操控 object_database 和 block_database 的 “上游” 模块.
// 代码 6.4
161 object_database::open(data_dir);
162
163 _block_id_to_block.open(data_dir / "database" / "block_num_to_block");
接下来, 如果这是节点的第一次启动 (说明从 object_database 中加载的对象中没有找到 global_property_object) 的话, 就要初始化创世状态, 而创世信息从里来呢? 请参考 Genesis 创世信息生成.
// 代码 6.5
165 if( !find(global_property_id_type()) )
166 init_genesis(genesis_loader());
创世过程的主要工作包括创建一些特殊和初始账户, 以及一些核心资产, 这些信息不用经过广播直接在本地出块, 因为所有其他节点也要执行要全同样的过程.
指的一提的是, 创世信息中的账户我本以为都是链上的公共账户或者委员会特殊账户之类的, 但没想到里面还有 9w 多的正常会员账户, 这些会员账户可谓是 bitshares 共链的 “创世居民”.
区块中保存了整条链的原始记录, 只要区块数据正确完好, 我们就能从这些数据中 replay 出一条一模一样的链.
好了, 本文就到此为止. 数据库篇后面就不写这么多了, 以后的文章会偏重于 graphene/bitshares 的应用程序架构和线程模型, 敬请期待.