Streaming-AppendEntries

背景：

目前 jraft 日志复制基于普通 RPC 的一请求一响应模型，在 RPC 层之上实现了日志的 pipeline 复制，这给上层带来了复杂的控制逻辑，比如要绑定线程以保证发送和接收顺序，要维护一个 inflights FIFO 队列来保证顺序，我们还为此专门实现了一个 MpscSingleThreadExecutor （多生产者单消费者线程池）来提高性能，等等，以上种种，核心原因还是因为受到 一请求一响应的模型的约束从而带来的实现复杂度。

目标：

当前，jraft 有一层 rpc 层的抽象层，并且在去年我们也支持了 grpc，所以我们是否可以利用 grpc 的 streaming 来实现一个新的 AppendEntries，如果抛开一请求一相应的模型，可能有如下好处：

1. 可以解除对 jraft 上层实现的高复杂度 pipeline 实现的依赖，极大的简化日志复制逻辑，让日志复制流程简单清晰
2. 可能会减少 bug，虽然这一块目前为止基本上没什么 bug，但也遇到过因为心跳进入了 inflights 队列而导致被排序从而心跳超时
3. 我们可以尝试合并 AppendEntries Response 来尽可能的减少网络开销和 leader 的处理逻辑开销，这个合并是指 follower 直接取消前边的 response， 只响应最新的 AppendEntries Request 即可，因为实际上 leader 只要收到最后一个 response 就足够了（leader 只是需要对应 follower 最新的 lastLogIndex 而已），当然，这个想法还需要要很多的正确性测试和效果验证，这个不是我创造的想法，更多来自这里 #500

我们需要做什么？

这个任务需要拆开为多个子任务，可能由多个人来实现，目前我们可以先尝试完成第一个任务，后面的任务需要更多细节设计，还需要再考虑。

• 1. 首先，我们要在 rpc api 中新增 streaming 接口（RpcClient, RpcServer），然后基于 grpc 实现之，对于 bolt 我们可以选择暂时不支持该能力，我觉得这可以作为一个新手任务，欢迎大家认领
• 2. 抽象出 Replicator，将现有的 Replicator 作为默认的一种实现
• 3. 基于 streaming API 实现一个崭新的 Replicator，我们可以将这个特性基于 SPI 扩展，使用哪种 Replicator 由用户选择
• 4. 要通过所有 jraft 单测以及 jepsen 验证
• 5. 最后，要有一个 benchmark 证明我们前面的工作没白费

[HHoflittlefish777]

请问这个任务还可以领取吗

[horizonzy]

先占个坑，对这个感兴趣。