raft
tigerbeetle
DISCONTINUED
Our great sponsors
raft | tigerbeetle | |
---|---|---|
7 | 37 | |
7,787 | 1,012 | |
1.5% | - | |
6.1 | 9.5 | |
3 days ago | over 1 year 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
-
SQLite Helps You Do Acid
Indeed!
I was so glad to see you cite not only the Rebello paper but also Protocol-Aware Recovery for Consensus-Based Storage. When I read your first comment, I was about to reply to mention PAR, and then saw you had saved me the trouble!
UW-Madison are truly the vanguard where consensus hits the disk.
We implemented Protocol-Aware Recovery for TigerBeetle [1], and I did a talk recently at the Recurse Center diving into PAR, talking about the intersection of global consensus protocol and local storage engine. It's called Let's Remix Distributed Database Design! [2] and owes the big ideas to UW-Madison.
-
20 years of payment processing problems
> By shifting business logic to stored procedures you avoid this.
Thanks, we considered stored procedures to bring the number of database queries down from 18 queries per payment to 1 query per payment. However, that would have provided only an order of magnitude improvement, and brought with it complexity of testing, compared to the state machine [1] we have in TigerBeetle.
At the same time, the biggest performance bottleneck is not only the multiple roundtrips, but the lack of first-class batching in the interface. What we do in TigerBeetle instead, is we send 8192 transfers in a single network request. This brings the network/disk cost equation down from 1 query per payment, to 1/8192 query per payment. It's like group commit, on steroids.
[1] https://github.com/coilhq/tigerbeetle/blob/main/src/state_ma...
> That's also why SQLite is very fast, as it runs in your application's memory as a library. But then your data is tied to the same limitations as the machine the application is on.
We could have made SQLite distributed, but SQLite also does not solve our storage fault model. For example, misdirected reads/writes, lost reads/writes, bitrot in the middle of the committed log. SQLite was also not explicitly designed to be integrated with a global consensus protocol as per ”Protocol-Aware Recovery for Consensus-Based Storage” from UW-Madison. For example, there are optimizations around storage fault tolerance in the commit log that you can do, or around deterministic storage across replicas for faster recovery, that you can't do with SQLite.
I had the experience of being part of a team in 2020 doing performance and safety analysis on Mojaloop [1], the open-source payments switch. The emphasis was mostly to identify performance bottlenecks. For example, graphing waterfalls of database queries, estimating expected vs actual concurrency, digging into latency spikes, timeout interactions, and missed group commit opportunities.
However, on the safety front, one of the most challenging issues was guaranteeing the rollback of funds in the event of failure, as part of the two-phase commit money transfer protocol, and coordinating this across multiple SQL queries, database transactions, Kafka queues, even multiple code repositories, especially as different systems experience clock drift or as disks or machines fail.
You want to ensure that the money either moves, or doesn't move, that it doesn't get lost somewhere in between.
Most payment systems re-implement all this business logic, again and again, so we extracted this from Mojaloop once-and-for-all, to create TigerBeetle [2], an open-source financial accounting database, that provides multi-AZ replication, automated leader election, and two-phase payments out-of-the-box.
[2] https://github.com/coilhq/tigerbeetle (Zig)
> It sounds like payments might be part of the larger concept of declarative programming (DP)
Yes, exactly! The idea with TigerBeetle's state machine [1] is to expose double-entry accounting as higher level financial primitives, so that developers can think in terms of declaring transfers from one account to another. The business logic behind the scenes is detailed, but the interfaces and data structures are simple.
[1] https://github.com/coilhq/tigerbeetle/blob/main/src/state_ma...
> Maybe TigerBeetle could be generalized to support any multi-step distributed process?
That's part of the plan, that the distributed database framework of TigerBeetle can be used as a ”distributed Iron Man suit” to support any kind of state machine.
-
How Safe Is Zig?
It's a pleasure. Let me know if you have any more questions about TigerBeetle. Our design doc is also here: https://github.com/coilhq/tigerbeetle/blob/main/docs/DESIGN....
-
Distributed Systems Shibboleths
> Allowing developers to think about a stream of operations that moves the databases from one legal state to another is super powerful.
It is super powerful. We used this RSM intuition to test TigerBeetle's strict serializability, by verifying state transitions the instant they happen, instead of trying to piece everything together and verify strict serializability after the test run.
Here it is in 49 lines of code:
https://github.com/coilhq/tigerbeetle/blob/477d6df366e2c10fa...
Surprisingly, some of the most powerful distributed systems algorithms or tools are actually deterministic. They're powerful because they can "load the dice" and so make the distributed system more intuitive for humans to reason about, more resilient to real world network faults, and do all this with more performance.
For example, Barbara Liskov and James Cowling's deterministic view change [1], which isn't plagued by the latency issues of RAFT's randomized dueling leader problem. Viewstamped Replication Revisited's deterministic view change can react to a failed primary much quicker than RAFT (heartbeat timeouts don't require randomized "padding" as they do in RAFT), commence the leader election, and also ensure that the leader election succeeds without a split vote.
Determinism makes all that possible.
Deterministic testing [2][3] is also your best friend when it comes to testing distributed systems.
[1] I did a talk on VSR, including the benefits of the view change — https://www.youtube.com/watch?v=Wii1LX_ltIs
[2] FoundationDB are pioneers of deterministic testing — https://www.youtube.com/watch?v=OJb8A6h9jQQ
[3] TigerBeetle's deterministic simulation tests — https://github.com/coilhq/tigerbeetle#simulation-tests
-
Lies we tell ourselves to keep using Golang
This is the chasm problem, where people don't use a technology because people aren't using that technology, thus the technology has difficulty gaining adoption. I did see that Zig does have it's own killer app and startup that's using Zig: TigerBeattle.
-
Ask HN: Codebases with great, easy to read code?
Are we allowed to share repos that we've written? :)
If so, then here's distributed consensus written in Zig:
https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...
Something that differentiates this from many other consensus implementations is that there's no networking/multithreading code leaking through, it's all message passing, so that it can be deterministically fuzz tested.
I learned so much, and had so much fun writing this, that I hope it's an enjoyable read—or please let me know what can be improved!
Control flow statements should always be on their own lines, then it's easy to find all of them by visually scanning top-down, without needing to look all the way down each line.
[1]: https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...
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