raft.tla
TLA+ specification for the Raft consensus algorithm (by ongardie)
Xline
A geo-distributed KV store for metadata management (by xline-kv)
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
raft.tla
Posts with mentions or reviews of raft.tla.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-10-30.
-
Introduction to Curp Protocol
For those interested in this sort of thing, see also Raft's TLA+ specification: https://github.com/ongardie/raft.tla
- TLA+ specification for the Raft consensus algorithm
Xline
Posts with mentions or reviews of Xline.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-12-08.
- Multi-region multi-cloud cluster. Best practices?
- Show HN: A Geo-Distributed KV Store for Metadata Management
-
Introduction to Curp Protocol
The CURP paper doesn't define a new leader election algorithm and presumes you use an existing one like raft. Xline is using raft based on the readme
https://github.com/xline-kv/Xline/tree/master/curp/tla%2B
warning, I skimmed and ctrl-fd for "leader election"
- Show HN: Geo-Distributed Metadata Management System
- Show HN: Xline0.4.0: Geo-Distributed KV Store for Metadata Management
-
Do people care about latency in blockchain?
Hi! We are developing an distributed KV database named Xline, which uses the CURP protocol to achieve up to a 50% reduction in latency compared to traditional distributed databases. As someone who is not well-versed in blockchain technology, I am curious to know whether low latency is the primary concern or if other factors are more important in this field?
-
Xline V0.3.0: A Geo-distributed KV Store For Metadata Management Built in Rust
Implement a storage engine layer to abstract the concrete storage engine, like rocksdb , and enable upper layer storage function (#185, #187)
- Show HN: Xline v0.3.0: A Geo-Distributed KV Store for Metadata Management
- Xline v0.2.0: Rust Powered Geo-distributed KV Store For Metadata Management
- Xline: A new geo-distributed KV store for metadata management
What are some alternatives?
When comparing raft.tla and Xline you can also consider the following projects:
paxi - Paxos protocol framework
roapi - Create full-fledged APIs for slowly moving datasets without writing a single line of code.
stateright - A model checker for implementing distributed systems.
raft
py2many - Transpiler of Python to many other languages