
Redlock - A ruby distributed lock using redis.
Distributed locks are a very useful primitive in many environments where different processes require to operate with shared resources in a mutually exclusive way.
There are a number of libraries and blog posts describing how to implement a DLM (Distributed Lock Manager) with Redis, but every library uses a different approach, and many use a simple approach with lower guarantees compared to what can be achieved with slightly more complex designs.
This is an implementation of a proposed distributed lock algorithm with Redis. It started as a fork from antirez implementation.
Compatibility
- It works with Redis server versions 6.0 or later.
- Redlock >= 2.0 only works with
RedisClient
client instance.
Installation
Add this line to your application's Gemfile:
gem 'redlock'
And then execute:
$ bundle
Or install it yourself as:
$ gem install redlock
Documentation
RubyDoc
Usage example
Acquiring a lock
NOTE: All expiration durations are in milliseconds.
lock_manager = Redlock::Client.new([ "redis://127.0.0.1:7777", "redis://127.0.0.1:7778", "redis://127.0.0.1:7779" ])
first_try_lock_info = lock_manager.lock("resource_key", 2000)
second_try_lock_info = lock_manager.lock("resource_key", 2000)
p first_try_lock_info
p second_try_lock_info
lock_manager.unlock(first_try_lock_info)
second_try_lock_info = lock_manager.lock("resource_key", 2000)
p second_try_lock_info
There's also a block version that automatically unlocks the lock:
lock_manager.lock("resource_key", 2000) do |locked|
if locked
else
end
end
There's also a bang version that only executes the block if the lock is successfully acquired, returning the block's value as a result, or raising an exception otherwise. Passing a block is mandatory.
begin
block_result = lock_manager.lock!("resource_key", 2000) do
end
rescue Redlock::LockError
end
Extending a lock
To extend the life of the lock:
begin
lock_info = lock_manager.lock("resource_key", 2000)
while lock_info
lock_info = lock_manager.lock("resource key", 3000, extend: lock_info)
end
rescue Redlock::LockError
end
The above code will also acquire the lock if the previous lock has expired and the lock is currently free. Keep in mind that this means the lock could have been acquired and released by someone else in the meantime. To only extend the life of the lock if currently locked by yourself, use the extend_only_if_locked
parameter:
lock_manager.lock("resource key", 3000, extend: lock_info, extend_only_if_locked: true)
Querying lock status
You can check if a resource is locked:
resource = "resource_key"
lock_info = lock_manager.lock(resource, 2000)
lock_manager.locked?(resource)
lock_manager.unlock(lock_info)
lock_manager.locked?(resource)
Any caller can call the above method to query the status. If you hold a lock and would like to check if it is valid, you can use the valid_lock?
method:
lock_info = lock_manager.lock("resource_key", 2000)
lock_manager.valid_lock?(lock_info)
lock_manager.unlock(lock_info)
lock_manager.valid_lock?(lock_info)
The above methods are not safe if you are using this to time critical code, since they return true if the lock has not expired, even if there's only (for example) 1ms left on the lock. If you want to safely time the lock validity, you can use the get_remaining_ttl_for_lock
and get_remaining_ttl_for_resource
methods.
Use get_remaining_ttl_for_lock
if you hold a lock and want to check the TTL specifically for your lock:
resource = "resource_key"
lock_info = lock_manager.lock(resource, 2000)
sleep 1
lock_manager.get_remaining_ttl_for_lock(lock_info)
lock_manager.unlock(lock_info)
lock_manager.get_remaining_ttl_for_lock(lock_info)
Use get_remaining_ttl_for_resource
if you do not hold a lock, but want to know the remaining TTL on a locked resource:
resource = "resource_key"
lock_info = lock_manager.lock(resource, 2000)
lock_manager.locked?(resource)
lock_manager.get_remaining_ttl_for_resource(resource)
lock_manager.locked?(resource)
lock_manager.get_remaining_ttl_for_resource(resource)
Redis client configuration
Redlock::Client
expects URLs, or configurations or Redis objects on initialization. Redis objects should be used for configuring the connection in more detail, i.e. setting username and password.
servers = [ 'redis://localhost:6379', RedisClient.new(:url => 'redis://someotherhost:6379') ]
redlock = Redlock::Client.new(servers)
To utilize Redlock::Client
with sentinels you can pass an instance of RedisClient
or just a configuration hash as part of the servers array during initialization.
config = {
name: "mymaster",
sentinels: [
{ host: "127.0.0.1", port: 26380 },
{ host: "127.0.0.1", port: 26381 },
],
role: :master
}
client = RedisClient.sentinel(**config).new_client
servers = [ config, client ]
redlock = Redlock::Client.new(servers)
Redlock supports the same configuration hash as RedisClient
.
Redlock configuration
It's possible to customize the retry logic providing the following options:
lock_manager = Redlock::Client.new(
servers, {
retry_count: 3,
retry_delay: 200,
retry_jitter: 50,
redis_timeout: 0.1
})
It is possible to associate :retry_delay
option with Proc
object. It will be called every time, with attempt number
as argument, to get delay time value before next retry.
retry_delay = proc { |attempt_number| 200 * attempt_number ** 2 }
lock_manager = Redlock::Client.new(servers, retry_delay: retry_delay)
For more information you can check documentation.
Run tests
Make sure you have docker installed.
$ make
Disclaimer
This code implements an algorithm which is currently a proposal, it was not formally analyzed. Make sure to understand how it works before using it in your production environments. You can see discussion about this approach at reddit and also the Antirez answers for some critics.
Contributing
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
)
- Commit your changes (
git commit -am 'Add some feature'
)
- Push to the branch (
git push origin my-new-feature
)
- Create a new Pull Request