Displaying 1 to 11 from 11 results

Atomix - Scalable, fault-tolerant distributed systems protocols and primitives for the JVM

  •    Java

Atomix is an event-driven framework for coordinating fault-tolerant distributed systems built on the Raft consensus algorithm. It provides the building blocks that solve many common distributed systems problems including group membership, leader election, distributed concurrency control, partitioning, and replication.

Finn - Fast Raft framework using the Redis protocol for Go

  •    Go

Finn is a fast and simple framework for building Raft implementations in Go. It uses Redcon for the network transport and Hashicorp Raft. There is also the option to use LevelDB, BoltDB or FastLog for log persistence.The reason for this project is to add Raft support to a future release of BuntDB and Tile38.

Raft - C implementation of the Raft consensus protocol

  •    C

Fully asynchronous C implementation of the Raft consensus protocol. The library has modular design: its core part implements only the core Raft algorithm logic, in a fully platform independent way. On top of that, a pluggable interface defines the I/O implementation for networking (send/receive RPC messages) and disk persistence (store log entries and snapshots).

replication-manager - Signal 18 repman - Replication Manager for MySQL / MariaDB / Percona Server

  •    Go

replication-manager is an high availability solution to manage MariaDB 10.x and MySQL & Percona Server 5.7 GTID replication topologies. It includes third-party libraries released under their own licences. Please refer to the vendor directory for more information.




evel - An Eventual Leader Election Library for Erlang

  •    Erlang

evel is a distributed leader election library which has eventual consistency. If the nodes which have started evel application eventually agree with the same member list (usually distributed erlang ensures it), each election will elect a single leader who is recognized by all of them.

sidecloq - Recurring / Periodic / Scheduled / Cron job extension for Sidekiq

  •    Ruby

There are several options for running periodic tasks with Sidekiq, including sidekiq-scheduler, sidekiq-cron, as well as Sidekiq Pro. Each tackles the problem slightly differently. Sidecloq is inspired by various facets of these projects, as well as resque-scheduler. I urge you to take a look at all of these options to see what works best for you. Tested on MRI > 2, JRuby and Rubinius. Basically, if you can run Sidekiq, you can run Sidecloq. Note that Sidekiq >= 5 does not support MRI ruby < 2.2.2.

dinghy - Dinghy implements leader election using the raft protocol

  •    Go

Dinghy implements leader election using part of the raft protocol. It might be useful if you have several workers but only want one of them at a time doing things.

bully-algorithm - [Go] - Bully algorithm visualization & implementation written in Golang.

  •    Go

This repository contains source code of an implementation of the bully algorithm written in Go and a small browser visualization tool. This has been made for learning purposes about distributed algorithms, Bully algorithm being the simplest leader election algorithm to implement.


broadcast-channel - :satellite: BroadcastChannel that works in New Browsers, Old Browsers, WebWorkers and NodeJs :satellite:

  •    Javascript

A BroadcastChannel allows simple communication between browsing contexts with the same origin or different NodeJs processes. This implementation works with old browsers, new browsers, WebWorkers and NodeJs. You can use it to send messages between multiple browser-tabs, iframes, WebWorkers and NodeJs-processes.

consultant - Helpful wrappers around Consul API

  •    Go

This package also provides a few "managed" types, complete with a Notification system.

goneli - Implementation of the NELI leader election protocol for Go and Kafka

  •    Go

Implementation of the NELI leader election protocol for Go and Kafka. goNELI encapsulates the 'fast' variation of the protocol, running in exclusive mode over a group of contending processes. Leader election is a straightforward concept, long-standing in the academic papers on distributed computing. For a set of competing processes, select one process that is a notional leader, ensuring that at-most one process may bear the leader status at any point in time, and that this status is unanimously agreed upon among the remaining processes. Conceptually, leader election is depicted below.