sofa-jraft
sofa-jraft copied to clipboard
适合新手的任务列表,欢迎认领
- [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
您好,我想试试第一个任务:并行压缩解压缩snapshot
@fengjiachun 您好,我想试试第二个任务。
@LXPWing , could you please provide the design of your implementation?
@hzh0425 could you please provide the design of your implementation?
@SteNicholas 您好,我是这样考虑的.主要是基于common-compress这个工具包
1.对于压缩而言:
-
Java自带ZipEntity压缩方式比较慢,会严重影响压缩效率。
-
commons-compress实现的多线程压缩方式效率足够高,但使用不当会占满当前服务器的CPU,导致压缩过程CPU占用率过高,严重影响正常的raft服务.
因此,可以通过控制ParallelScatterZipCreator类所使用的线程池的线程数,控制压缩所需占用的CPU,在提升压缩性能的同时减少对正常业务的影响 当然,具体的线程数需要经过测试
2.对于解压缩而言:
- commons-compress提供了ZipFile这个类,用于读取压缩文件,并可以返回该压缩文件中的每一个文件条目ZipEntry,每一个ZipEntry可以单独的解压.为此,我想同样可以通过线程池的方式,将解压ZipEntry的任务投递到线程池中执行.
3.考虑到压缩和解压缩都用到了线程池,我想是否应该开辟一个专门的线程池用于压缩和解压缩呢?
4.最后,我已经尝试过上述的方法,比起单线程压缩更快更高效.
@hzh0425 👍, 线程数可以作为一个 NodeOptions 的配置选项来提供给用户,建议给出测试对比报告,然后默认一个设置值。
@hzh0425 为了防止出现意料之外的 bug,并行压缩也可以整体作为一个选项是否开启,默认还是走目前的逻辑。
@killme2008 好的,十分感谢,那我开始尝试这个方案.
@hzh0425 思路很清晰了,可以开始了,十分感谢
@hzh0425 可以在 #569 里随意回复一句,我好 assign 给你
认领 #503。
设计说明
需要断点续传的原因包括网络原因导致的:
- Snapshot下载失败
- InstallSnapshot RPC调用失败或超时
因此,增加如下容错机制:
- 给每次安装Snapshot关联一个会话,如果一个会话中的Snapshot文件下载过程在中间失败了,下载过程会执行断点续传。
- InstallSnapshot改为非阻塞式调用,其执行结果分为Success、Fail、Pending。一次安装Snapshot动作会通过多次InstallSnapshot调用完成,在结果为Pending时会再次重试。
实现思路:
- 给InstallSnapshot实现Session,并将LocalSnapshotCopier关联到会话中,同一个Session内只会启动一个LocalSnapshotCopier。
- 目前snapshot文件是按照分块形式进行下载,其中的重试机制可以满足断点续传的功能需求,无需改动。
- 修改SnapshotExecutor.installSnapshot方法的Request和Response,用于识别同一个Session。
- 将Load操作也关联到Session中,具体设计是取消installSnapshot方法中的
curCopier.join()
操作,将downloadSnapshot和loadSnapshot包装成一个新的任务提交到后台线程执行,该任务的执行结果作为整个session的执行结果。
@312223105 欢迎尝试,目前缺少 snapshot 文件的分片逻辑,可能也需要搞下,分片理论上可以做并行下载,不过这是未来的优化方向,暂时可以放后面。