distributedlock v1.0.0

Uses a Redis instance to allow distributed lock. This allows a certain process to make use of a resource one at a time.

• Allows a single redis instance that uses redlock algorithm to be use
• Or in case of failover support a Redis sentinel is used to manage multiple redis instance that sa master/slave roles.

Requirements

All Redis Instance

• Make sure the dump.rdb can be written. For single instances this way redis does not fail when writing to disk. This enables the slave redis replication.

Multiple Redis Instance

• Redis instances/sentinel are should be running for the lock dependency to run, since this module will try to connect to the sentinel to get the master redis instance.

Redis config (redis.conf)

All Redis Instance
notify-keyspace-events KEA
port <port #>
slave-read-only yes
slave-priority <priority number> //the lower to more in priority getting to be master

Slave Redis Instance
slaveof <masterip|machine name> <masterport>

Sentinel Config
sentinel monitor master <redis master instance> <redis master port> 1
sentinel down-after-milliseconds master 2000
sentinel failover-timeout master 3000

Redis Readings

Redis replication http://redis.io/topics/replication Redis Sentinel http://redis.io/topics/sentinel

Usage

//Single Redis

var dlock = require('distributedLock');
var lock = new dlock({key: 'adm', host:'localhost', port:6379});

lock.on("acquired", function (key) {
  console.log('*** Startup ***');
});


//Multiple Redis with fail ove support
var dlock = require('distributedLock');
// take note that instead of declaring host we declared the sentinel values. master/slaves are automatically discover when this modules connects to a redis sentinel
var lock = new dlock({key: 'adm', sentinel: {host: 'localhost', port: 26379}});

lock.on("acquired", function (key) {
  console.log('*** Startup ***');
});

Scenarios

See test scenarios ./test/

API

Events

acquired

acquired is emitted when lock has been successfully acquired.

var lock = new DistributedLock();
lock.on('acquired', function(key){
  //do my stuff
});

released

released is emitted when a lock has been obtained and has been released.

var lock = new DistributedLock();
lock.on('released', function(key){
  //do my stuff on lock released
});

failed

failed is emitted when a lock is NOT obtained after trying to acquire lock

var lock = new DistributedLock();
lock.on('failed', function(key){
  // lock is not aquired do some processing
});

listening

listening is emitted when lock is not acquired but is waiting for the lock has been released.

var lock = new DistributedLock();
lock.on('listening', function(key){
  // lock is not aquired do some process while it start to listen for the lock
});

Methods

release

When called,

• it releases the current lock and ends the session.
• if the lock was not acquired and is currently in monitoring mode, this ends the current monitoring and redis session.

var lock = new DistributedLock();
lock.release();

Notes

• When multiple redis is used for the setup to support failover: It is best o give the TTL a higher value since it takes a while before the the responsibility is switched to another redis. This is due to the Redis Sentinel timing. On my test its ideal to have TTL: 10000 and renewTTL of 5000. You can play around with the timing but this works best so that the sentinel timing will not produce a timing problem. The timing greatly increases the switching timing when renewing/reaquiring the locks. ** when a master redis instance goes down, another redis instance is promoted to be a master. The instance that went down can be brought up but will have the role of a slave

Future Plans

• Add more test to mimic shutting down servers and putting them back up again and make sure the the lock is managed correctly.

License

MIT