You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🪵🪵🪵 Raft is not yet good enough.
This project intends to improve raft as the next-generation consensus protocol for distributed data storage systems (SQL, NoSQL, KV, Streaming, Graph ... or maybe something more exotic).
Currently, openraft is the consensus engine of meta-service cluster in databend.
Get started: The guide is the best place to get started,
followed by the docs for more in-depth details.
Openraft API is not stable yet. Before 1.0.0, an upgrade may contain incompatible changes.
Check our change-log. A commit message starts with a keyword to indicate the modification type of the commit:
Change: if it introduces incompatible changes.
Feature: if it introduces compatible non-breaking new features.
Fix: if it just fixes a bug.
Branch main has been under active development.
The main branch is for the 0.8 release.
The features are almost complete for building an application.
The performance isn't yet fully optimized. Currently, it's about 48,000 writes per second with a single writer.
It is fully reactive and embraces the async ecosystem.
It is driven by actual Raft events taking place in the system as opposed to being driven by a tick operation.
Batching of messages during replication is still used whenever possible for maximum throughput.
Storage and network integration is well defined via two traits RaftStorage & RaftNetwork.
This provides applications maximum flexibility in being able to choose their storage and networking mediums.
All interaction with the Raft node is well defined via a single public Raft type, which is used to spawn the Raft async task, and to interact with that task.
The API for this system is clear and concise.
Log replication is fully pipelined and batched for optimal performance.
Log replication also uses a congestion control mechanism to help keep nodes up-to-date as efficiently as possible.
It fully supports dynamic cluster membership changes with joint config.
The buggy single-step membership change algo is not considered.
See the dynamic membership chapter in the guide.
Details on initial cluster formation, and how to effectively do so from an application's perspective,
are discussed in the cluster formation chapter in the guide.
Automatic log compaction with snapshots, as well as snapshot streaming from the leader node to follower nodes is fully supported and configurable.