sofa-jraft icon indicating copy to clipboard operation
sofa-jraft copied to clipboard

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

Open fengjiachun opened this issue 3 years ago • 12 comments

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

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

fengjiachun avatar May 28 '21 09:05 fengjiachun

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

hzh0425 avatar May 30 '21 08:05 hzh0425

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

LXPWing avatar May 31 '21 02:05 LXPWing

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

SteNicholas avatar May 31 '21 02:05 SteNicholas

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

SteNicholas avatar May 31 '21 02:05 SteNicholas

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

1.对于压缩而言:

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

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

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

2.对于解压缩而言:

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

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

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

hzh0425 avatar May 31 '21 03:05 hzh0425

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

killme2008 avatar May 31 '21 03:05 killme2008

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

killme2008 avatar May 31 '21 03:05 killme2008

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

hzh0425 avatar May 31 '21 03:05 hzh0425

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

fengjiachun avatar May 31 '21 03:05 fengjiachun

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

fengjiachun avatar May 31 '21 03:05 fengjiachun

认领 #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的执行结果。

312223105 avatar Jun 04 '21 06:06 312223105

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

killme2008 avatar Jun 04 '21 07:06 killme2008