Dongsheng He
Dongsheng He
> 在Closure里处理不是很优雅。这里是否可以抽象一个通用的机制，卡住未来的某个log index做snapshot（将log index提交给fsm caller的on_apply线程），这个未来可以扩展到一些额外的用途，例如做副本间的一致性校验（相同的log index的snapshot数据应该是等价的）。 > > 然后具体到本issue，只需要在snapshot开始/完成时计算下一次的卡位点即可。 > > NodeImpl的参数上，可以增加一个snapshot方式的参数，interval/log length选一个。log length需要改一个更贴切的名字 卡住未来的某个 log index 做 snapshot，这 个 log index 一定要求是一个精确值吗？比如卡位点在 10， 那么 index 为 10 的 log...
1. 增加SnapshotTriggerType参数(`NONE`，`TIMER`， `LOG_INTERVAL`) 其中`NONE`不自动触发快照，`TIME`代表定时触发快照，`LOG_INTERVSAL`类型, 是当日志长度满足一定要求时触发，也就是说相邻两个快照之间的日志间隔数目是一定的。具体实现是在fsm_call 的 do_committed 中判断，当applied_index到达特定的 log index 点后原地触发snapshot。 2. 之前的snapshot的接口都是向execution_queue提交任务，为了能够实现原地触发调用，给相应的接口增加in_place 参数来区分是否在原地触发。
> 参见评论，另外，需要补充一些单测 已经增加相关测试用例
在LogManager::append_entries 里面，bthread::execution_queue_execute(_disk_queue, done) 提交磁盘任务，这里是异步的，提交任务后会立即返回，继续向下执行wakeup_all_waiter，这里会释放掉LogManager::_mutex，并返回到NodeImpl::handle_append_entries_request 释放掉NodeImpl::_mutex，应该是不会发生死锁。
> 启动单个节点，成为 leader 以后，重启 leader 节点。 _leader_term 在 leader 重启以后没有正确设置，导致 is_leader 函数返回值不符合预期。 重启 leader 之后，该节点可能已经不是 leader 了。
可以参考 https://github.com/baidu/braft/issues/292 你说的这种情况是存在的，正确的做法应该是先移除这个节点，然后再加入这个节点。
This is because when the follower restart, leader could to send heartbeat to it, but didn't handle the log mismatch situation. Follower will set response success to false when log...
https://github.com/baidu/braft/pull/318
@googlebot I signed it!
client直接使用http协议？