raft
tigerbeetle
Our great sponsors
raft | tigerbeetle | |
---|---|---|
7 | 44 | |
7,787 | 6,534 | |
1.5% | 45.5% | |
6.1 | 9.9 | |
2 days ago | 5 days ago | |
Go | Zig | |
Mozilla Public License 2.0 | Apache License 2.0 |
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
-
Leader election library
Depending on your exact needs, you could try HashiCorp's Raft implementation: https://github.com/hashicorp/raft
-
Implementing a distributed key-value store on top of implementing Raft in Go
I have found the performance tests very tricky to get to pass without having any input from others. The assignment is really very unforgiving, I would wager the test suite is comparable to how commercial Raft implementations are tested (e.g. https://github.com/hashicorp/raft)
- Raft Is So Fetch: The Raft Consensus Algorithm Explained Through Mean Girls
-
Concurrency in Go is hard
While searching on GitHub, I found a pull request in the Raft implementation by Hashicorp (a distributed consensus algorithm), which we can use to demonstrate the following problem. Let’s start by showing the code (at api.go):
-
rqlite, the light distributed database built with Go and SQLite, v7.2 now with autoclustering via DNS and DNS SRV
Production-grade distributed consensus system.
-
Raft Consensus Protocol
In general Hashicorp's repos are high quality:
https://github.com/hashicorp/raft
Example application: https://github.com/Jille/raft-grpc-example
tigerbeetle
- Factor is faster than Zig
-
The Raft Consensus Algorithm
Maelstrom [1], a workbench for learning distributed systems from the creator of Jepsen, includes a simple (model-checked) implementation of Raft and an excellent tutorial on implementing it.
Raft is a simple algorithm, but as others have noted, the original paper includes many correctness details often brushed over in toy implementations. Furthermore, the fallibility of real-world hardware (handling memory/disk corruption and grey failures), the requirements of real-world systems with tight latency SLAs, and a need for things like flexible quorum/dynamic cluster membership make implementing it for production a long and daunting task. The commit history of etcd and hashicorp/raft, likely the two most battle-tested open source implementations of raft that still surface correctness bugs on the regular tell you all you need to know.
The tigerbeetle team talks in detail about the real-world aspects of distributed systems on imperfect hardware/non-abstracted system models, and why they chose viewstamp replication, which predates Paxos but looks more like Raft.
[1]: https://github.com/jepsen-io/maelstrom/
[2]: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/DE...
- Fastest Branchless Binary Search
-
CWE Top Most Dangerous Software Weaknesses
> There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs.
Tell that to the authors of new memory unsafe languages (like Zig) and creators of new project in those languages (like https://tigerbeetle.com) :(
- Problems of C, and how Zig addresses them
- File for Divorce from LLVM
-
Zap – fast back ends in Zig
Seeing this, and the use of zig for https://github.com/tigerbeetledb/tigerbeetle I wonder if zig might become a good tradeoff vs rust for servers if in long term it's more readable and maintainable and with a different approach to quality.
I would also be interested to hear the compile time, binary size and memory usage of those example apps.
Looks like the underlying facil.io library hasn't seen any commits since 2021, so that's a bit of a red flag. https://github.com/boazsegev/facil.io
-
Significant examples of Zig software (June 2023)?
About three years ago, we had a thread called "Significant examples of Zig software?". Some time has passed, and there have been fairly large Zig code bases that have surfaced since, such as TigerBeetle (cc /u/eatonphil), or adoption at places like Uber.
-
I think Zig is hard but worth it
This is basically what I've come to do in the Zig scripts I write at work.
It took a bit of getting used to when I joined but we agreed as a team to have all meaningful scripts written in Zig not bash (for one, bash doesn't work on Windows without WSL and we need to support Windows builds/testing/etc.).
It makes about as much sense as any other cross-platform scripting option once I got used to it!
Some examples:
Docs generation: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
Integration testing sample code: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
Running a command wrapped in a TigerBeetle server run: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
What are some alternatives?
serf - Service orchestration and management tool.
tendermint - ⟁ Tendermint Core (BFT Consensus) in Go
torrent - Full-featured BitTorrent client package and utilities
etcd - Distributed reliable key-value store for the most critical data of a distributed system [Moved to: https://github.com/etcd-io/etcd]
dragonboat - A feature complete and high performance multi-group Raft library in Go.
DHT - BitTorrent DHT Protocol && DHT Spider.
ringpop-go - Scalable, fault-tolerant application-layer sharding for Go applications
grpc-go - The Go language implementation of gRPC. HTTP/2 based RPC
raft-grpc-example - Example code for how to get hashicorp/raft running with gRPC
Olric - Distributed in-memory object store. It can be used as an embedded Go library and a language-independent service.
go-health - Library for enabling asynchronous health checks in your service
redis-lock - Simplified distributed locking implementation using Redis