适合新手的任务列表，欢迎认领

[fengjiachun]

• 1. 并行压缩解压缩能力，主要是优化加载 snapshot 的速度，见 Compress/Decompress snapshot in parallel #569 - 已合并进 master
• 2. 将一个运行中的 learner 动态改成 follower，见 [Question]Raft learner to follower #560 - 已合并进 master
• 3. Snapshot 传输实现断点续传机制，见 Snapshot 安装实现断点续传机制 #503 - 已提交 PR，CR进行中
• 4. 安全漏洞升级，升级依赖 org.apache.commons:commons-compress 到 1.21 或以上，并通过所有单元测试 安全漏洞升级 #673 - 已被认领
• 5. 在 rpc api 中新增 streaming 接口（RpcClient, RpcServer），然后基于 grpc 实现之，见 Streaming-AppendEntries #672 的第一个子任务

申请人条件不限，申请的话可以在留言里简单说下自己的设计~
参考资料：
SOFAJRaft文档
SOFAJRaft source/architecture materials from community

[hzh0425]

您好,我想试试第一个任务:并行压缩解压缩snapshot

[LXPWing]

@fengjiachun 您好，我想试试第二个任务。

[SteNicholas]

@LXPWing , could you please provide the design of your implementation?

[SteNicholas]

@hzh0425 could you please provide the design of your implementation?

[hzh0425]

@SteNicholas 您好,我是这样考虑的.主要是基于common-compress这个工具包

1.对于压缩而言:

• Java自带ZipEntity压缩方式比较慢,会严重影响压缩效率。

• commons-compress实现的多线程压缩方式效率足够高，但使用不当会占满当前服务器的CPU,导致压缩过程CPU占用率过高,严重影响正常的raft服务.

  因此,可以通过控制ParallelScatterZipCreator类所使用的线程池的线程数,控制压缩所需占用的CPU,在提升压缩性能的同时减少对正常业务的影响
  当然,具体的线程数需要经过测试

2.对于解压缩而言:

• commons-compress提供了ZipFile这个类,用于读取压缩文件,并可以返回该压缩文件中的每一个文件条目ZipEntry,每一个ZipEntry可以单独的解压.为此,我想同样可以通过线程池的方式,将解压ZipEntry的任务投递到线程池中执行.

3.考虑到压缩和解压缩都用到了线程池,我想是否应该开辟一个专门的线程池用于压缩和解压缩呢?

4.最后,我已经尝试过上述的方法,比起单线程压缩更快更高效.

[killme2008]

@hzh0425 👍， 线程数可以作为一个 NodeOptions 的配置选项来提供给用户，建议给出测试对比报告，然后默认一个设置值。

[killme2008]

@hzh0425 为了防止出现意料之外的 bug，并行压缩也可以整体作为一个选项是否开启，默认还是走目前的逻辑。

[hzh0425]

@killme2008 好的,十分感谢,那我开始尝试这个方案.

[fengjiachun]

@hzh0425 思路很清晰了，可以开始了，十分感谢

[fengjiachun]

@hzh0425 可以在 #569 里随意回复一句，我好 assign 给你

[312223105]

认领 #503。

设计说明

需要断点续传的原因包括网络原因导致的：

1. Snapshot下载失败
2. InstallSnapshot RPC调用失败或超时

因此，增加如下容错机制：

1. 给每次安装Snapshot关联一个会话，如果一个会话中的Snapshot文件下载过程在中间失败了，下载过程会执行断点续传。
2. InstallSnapshot改为非阻塞式调用，其执行结果分为Success、Fail、Pending。一次安装Snapshot动作会通过多次InstallSnapshot调用完成，在结果为Pending时会再次重试。

实现思路：

1. 给InstallSnapshot实现Session，并将LocalSnapshotCopier关联到会话中，同一个Session内只会启动一个LocalSnapshotCopier。
2. 目前snapshot文件是按照分块形式进行下载，其中的重试机制可以满足断点续传的功能需求，无需改动。
3. 修改SnapshotExecutor.installSnapshot方法的Request和Response，用于识别同一个Session。
4. 将Load操作也关联到Session中，具体设计是取消installSnapshot方法中的curCopier.join()操作，将downloadSnapshot和loadSnapshot包装成一个新的任务提交到后台线程执行，该任务的执行结果作为整个session的执行结果。

[killme2008]

@312223105 欢迎尝试，目前缺少 snapshot 文件的分片逻辑，可能也需要搞下，分片理论上可以做并行下载，不过这是未来的优化方向，暂时可以放后面。