Pages

▼

Monday, 6 April 2020

Redundis

Redis high-availability cluster using Sentinel to transparently proxy connections to the active primary member  - with full redis capability.
Redundis is a smart, sentinel aware proxy for redis that allows redis clients to not care about failover of the redis master node.
Connections are automatically forwarded to the master redis node, and when the master node fails over, clients are disconnected and reconnected to the new master node.

Status

Complete/Stable

Quickstart

cd $GOPATH

go get -u -v github.com/nanopack/redundis/

Simply run redundis to start redundis with the default settings or redundis -c config.json to use config from a file.

Config

Redundis can be configured via a config file, or command line flags. Any configuration in a specified config file will overwrite any cli flags.

Config Flags

redundis -h will show usage and a list of flags:
redundis redis-proxy

Usage:
  redundis [flags]

Flags:
  -c, --config-file="": Config file location for redundis
  -l, --listen-address="127.0.0.1:6379": Redundis listen address
  -L, --log-level="info": Log level [fatal, error, info, debug, trace]
  -t, --master-wait=30: Time to wait for node to transition to master (seconds)
  -m, --monitor-name="test": Name of sentinel monitor
  -r, --ready-wait=30: Time to wait to connect to redis|sentinel (seconds)
  -s, --sentinel-address="127.0.0.1:26379": Address of sentinel node
  -p, --sentinel-password="": Sentinel password
  -w, --sentinel-wait=10: Time to wait for sentinel to respond (seconds)

Config File

You can specify a config file by using redundis -c config.json
{
  "listen-address": "127.0.0.1:6379",
  "sentinel-address": "127.0.0.1:26379",
  "sentinel-password": "",
  "monitor-name": "test",
  "master-wait": 30,
  "ready-wait": 30,
  "sentinel-wait": 10,
  "log-level": "info"
}

Redis Setup

Each redis node will be configured as follows:
+----------+
| redis    | - redis-server running on port 6380 with sentinel configured
| sentinel | - sentinel configured and started (default listen port of 26379)
| redundis | - proxies incoming connections to master redis (determined by talking to local sentinel)
| flip*    | - manages cluster vip that users connect to
+----------+
* = optional

Limitations

Currently, only connecting to one sentinel is supported. It could be extended in the future to connect to a different sentinel incase of sentinel failure, but right now this is not needed.
frm https://github.com/nanopack/redundis
-----------------------------------

Transparent sharding/failover-handling proxy for redis and redis sentinel.

breadis

A proxy for redis cluster which automatically handles command redirection and failover detection
To the client, acts just like a redis server. No changes necessary for any redis client to communicate with it.

Usage

Compile with
go build
See command-line options with
./breadis --help
Load command-line options from config file with
./breadis --config
See example config file with
./breadis --example

Use case

breadis acts as a simple proxy to an entire redis cluster, acting exactly the same as a normal single redis instance (so any existing redis driver can already talk to breadis).
This might seem a bit silly, since you could just use a cluster-aware driver in your application to interact with the redis cluster. But this has two downsides:
  • You have to know you're interacting with a redis cluster in the first place, which may not always be the case. For instance, if in a dev environment an application commmunicates with a single redis on localhost:6379, but in production there is a cluster on multiple other boxes, that's something the application has to differentiate. Instead, the dev environment could keep using a single local redis, but in production the application server could have breadis listening on port 6379, meaning the application wouldn't have to know the difference.
  • The redis cluster handling isn't trivial, and works best when there is a persistant process managing it. This may not be possible in stateless, request based languages (e.g. PHP) or if you're executing a bunch of one-off scripts which use redis cluster. For these cases having a breadis instance handle the hard parts and just having the application hit it instead of doing the hard parts itself.
at