doc001

内部版本在测试这个功能，时机成熟了会同步到github

> > 内部版本在测试这个功能，时机成熟了会同步到github > > 期待，能问下大概的预期时间吗 顺利的话，4月份能同步过来

> 另外问下，witness观察者模式有考虑么 公司内有个团队之前沟通过witness在他们的计划里，具体的进展现在不太清楚

> > > 另外问下，witness观察者模式有考虑么 > > > > > > 公司内有个团队之前沟通过witness在他们的计划里，具体的进展现在不太清楚 > > 那么learner预计什么时候能够合入呢 learner 可以合入了，这个patch有些大，加上最近有些忙，所以还没同步过来

需要业务层自己处理，braft实际上不会主动删数据，垃圾副本的gc由业务层自己进行。

> 能构造ut去复现么? 可以的，我加一下

嗯，应该在获取 _leader_id 之后释放

Raft的串行化阶段对这种超低延时的存储系统不够友好。这个改造方案里最复杂的其实是配置变更

reject term_unmatched AppendEntries，一般是有选主发生了

0. 嗯，压缩算法可能让数据更小，但是基本原理是这样的。主要是 raft 写下去的日志在 commit 前可能会被 truncate，从正确性的角度，这一步不能省略。leveldb自己的log选项可以根据需要进行调节，保证snapshot的点持久化即可，然后通过日志回放来保证数据正确性 1. 基于 leveldb/rocksdb 的 snapshot 可以做到什么都不做，只生成一个文件列表（这个文件列表不需要是真实存在的文件，怎么解释业务自己决定，通过 snapshot file system adaptor 来 hook 读写过程即可），拖snapshot的时候拖取更新的版本的数据。靠日志回放来保证最终的正确性 2. 每个节点单独维护 3. 需要拖取全量数据，启动过程代价和 snapshot load 是一样的