OpenACID Blog
Raft’s single-server membership change carries two problems: its middle state can turn one datacenter into a single point of failure, and the original algorithm could lose a committed entry. Let us look at membership change through quorum sets, and see why joint consensus is the answer.
timestamp_oracle is a 200-line timestamp service on EzRaft. A background task reserves ranges through Raft; next_timestamp allocates from memory. Leader leases and term-scoped caches keep the sequence strictly increasing across failovers, with no Raft write on the request path.
EzRaft builds on OpenRaft and hides the storage, networking, and service layers. Define just four things—Request, Response, apply, and read—and you have a fault-tolerant, three-node distributed KV store.
raf is an experimental Raft variant that does not persist currentTerm as a separate field. Instead, each election reserves a log index, and that index becomes the leader term.
Analyzes a replication session isolation bug in Raft implementations. When a node rejoins the cluster within the same term, delayed AppendEntries responses can corrupt progress tracking, causing infinite retry loops. While data safety remains intact, it creates operational issues like resource exhaustion. Uses raft-rs as a case study to examine trigger conditions and solutions.
深入分析 Raft 实现中 IO 重排序导致数据丢失的问题。问题不在 Raft 的设计，而在于实现中内存状态与持久化状态的区分导致的陷阱
Is the single-log-entry approach to Raft configuration change simpler than the standard Joint Consensus?
I got it wrong in my previous article. The IO ordering bug in Raft isn’t about the protocol design—it’s about the subtle trap that emerges when implementations split state into in-memory and persisted state. Here’s what actually happens.
Writing logs before persisting term in Raft can silently destroy committed data. Here’s why production systems like TiKV and HashiCorp Raft carefully control IO order—and three battle-tested solutions.
单条日志实现Raft配置变更的方法，对比标准的Joint Consensus更简洁吗？
Openraft 中对 linearizable read 流程的优化
从古至今, 武林中有两招绝学, paxos 和 raft, 三十天了, 我用了整整三十天的时间, 将两招绝学并成了一整招, 看好了: abstract-paxos
Raft 在单步成员变更的设计上存在缺陷, 一定要抛弃单步变更, 使用joint consensus
通过减少多数派读写中参与者的数量, 可以实现分布式系统某些特定场景的优化, 以及介绍这些优化对系统可用性产生的影响, 根据什么标准来选择和调整这些参数.