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

A production-grade java implementation of RAFT consensus algorithm.

Results 89 sofa-jraft issues
Sort by recently updated
recently updated
newest added

### Motivation: #874 ### Modification: Describe the idea and modifications you've done. ### Result: Fixes #. If there is no issue then describe the changes introduced by this PR.

cla:yes
size/L

jraft有没有提供一些类似spi的抽象扩展接口,可以让我们自己去实现多个节点一致性验证,或者存储,比如可以根据jraft的抽象实现类似分布式事务

### Your question 快照在99%的情况是用于本地重启,而用于网络传输的机会比较少。 所以为了降低 CPU 使用率,建议可以调整压缩级别。 ### Your scenes Describe your use scenes (why need this feature) ### Your advice Describe the advice or solution you'd like ### Environment...

The copyright notices should remain as-is.

cla:yes
size/XS

## RFC: multi-generation log cache As discussion in #840 , jraft keeps a cache for latest log entries, it's unlimited and may consume too much memory under write-heavy workload or...

enhancement
help wanted

### Your question 现在对于线性一致性读是通过 RaftOptions.readOnlyOptions 配置进行全局控制的。 不能针对业务请求来区分,不够灵活。 ### Your scenes ### Your advice 建议 ReadIndexClosure 增加 ReadOnlyOption 来控制当前请求线性一致性的类型。

help wanted
good first issue

### Describe the bug We're using SOFAJRaft in one of our project. Nowadays, sometimes it's found that IOException is raised when snapshot is generated/saved: ``` 2022-05-31 12:12:14,891 JRaft-Closure-Executor-14 WARN [Utils:341]...

## Add streaming APIs (RpcClient, RpcServer), implement it based on gRPC. This is a subtask that belongs to the first step of #672 In this subtask, we need a streaming...

enhancement
help wanted

### 背景: 目前 jraft 日志复制基于普通 RPC 的一请求一响应模型,在 RPC 层之上实现了日志的 pipeline 复制,这给上层带来了复杂的控制逻辑,比如要绑定线程以保证发送和接收顺序,要维护一个 inflights FIFO 队列来保证顺序,我们还为此专门实现了一个 `MpscSingleThreadExecutor` (多生产者单消费者线程池)来提高性能,等等,以上种种,核心原因还是因为受到 `一请求一响应的模型`的约束从而带来的实现复杂度。 ### 目标: 当前,jraft 有一层 rpc 层的抽象层,并且在去年我们也支持了 grpc,所以我们是否可以利用 grpc 的 streaming 来实现一个新的 AppendEntries,如果抛开一请求一相应的模型,可能有如下好处: 1....

help wanted
high priority

**背景现象:** 这个问题和我之前提的那个issue([https://github.com/sofastack/sofa-jraft/issues/830])是类似的,我们新启的follower需要追的log比较多,会达到亿级别。 append log有可能会堵塞住jraft log disruptor, 从而造成append log请求超时。 最后在如下代码的判断里,因为append log请求超时超过了ElectionTimeoutMs,则add peer task会失败,replicator会停止,follower永远都无法加入集群了。(ElectionTimeoutMs我们使用的是默认的1000ms) https://github.com/sofastack/sofa-jraft/blob/1d57d082d4fe50cc11f63cde7134efe026dbdbd8/jraft-core/src/main/java/com/alipay/sofa/jraft/core/NodeImpl.java#L2174 **如何解决这个问题** 关于限流 之前有提过通过限流leader append log的并发量,避免follower在追进度时出现堵塞情况,从而影响heartbeat或append log。 我这里发现如下的参数是比较影响并发量的 private int maxEntriesSize = 1024; //单批次日志数量 private int maxReplicatorInflightMsgs =...