Introduction
Last month I shared a simple but effective strategy of how to create a Redis Mutex in your Ruby applications to handle cross-process/cross server synchronisation. As a quick recap, the problem this is solving is if you need to use locking synchronisation to control access across multiple systems to a resource. In this case a standard Ruby Mutex won't help you as you are bound within the constraints of a single process. And a file mutex (for example) won't help you because you're bound within the constraints of a single server (NAS implementations aside :)
Now, looking at the RedisMutex implementation we shared last week, there is an obvious but slightly tricky in-efficiency with it. To illustrate this let me refresh your memory by outlining the essential workflow below:
1. try and take the lock (atomically) --> fail
2. wait <recheck frequency seconds>>
3. try and take the lock (atomically) --> fail
4. wait <recheck frequency seconds>>
5. try and take the lock (atomically) --> success!
So what you see is that we have a recheck frequency seconds during which time we are waiting (for simplicity lets call this recheck_wait from here on). If we make recheck_wait very small then we are going to end up hitting our Redis server a lot (causing unnecessary load there) and if we make recheck_wait too big then we end up with periods of time where the lock is released, but we are still waiting! To get around this we can extend our RedisMutex class to make use of Redis Key Event Notifications!
As with the last post, I'll talk through the way that we implemented the code below. Please feel free to use it or reach out if you have any feedback or comments. Remember to always understand the code you're running and using it is at your own risk; Cloud 66 can not be held liable.
This time you'll need a Redis Server running at least version 2.8 to use this Mutex.
Implementation
1. Redis Initializer
- Once a redis connection is in a subscription mode, it can only perform subscription related actions - so we need a pool of redis connections to use exclusively for our subscription events. To manage this pool we use Mike Perham's excellent connection_pool gem. (Unrelated: we're huge fans of Mike's sidekiq gem too)
- Redis needs to be told that it should raise key events for us. This should be done when your application starts up. You can choose which events to receive notifications on - we need the following ones:
- K: Keyspace events published with __keyspace@DB
- g: Generic commands like DEL, EXPIRE, RENAME, ...
- x: Expired events (events generated every time a key expires)
# Redis Initializer Implementation
require 'connection_pool'
# this is a pool for our regular redis connections
$conn_pool = ConnectionPool.new do
Redis.new(:host => redis_server, :port => 6379)
end
# this is a pool for our subscription redis connections
# note: choose size and timeout that suit your own needs
# if your size is not large enough you may run out of connections
size = 5
timeout = 5
$subs_pool = ConnectionPool.new(size: size, timeout: timeout) do
Redis.new(:host => redis_server, :port => 6379)
end
# tell redis we want notifications for specific key events
$subs_pool.with do |conn|
conn.config(:set, 'notify-keyspace-events', 'Kgx')
end
2. Mutex Implementation
- Instead of waiting a set time for keys to expire we can now simply subscribe to specific Redis
delorexpiredevents that are raised for our key; and move on in that case.
# cross-process/cross-server mutex
class RedisMutex
attr_accessor :global_scope,
:max_lock_time
LOCK_ACQUIRER = "return redis.call('setnx', KEYS[1], 1) == 1 and redis.call('expire', KEYS[1], KEYS[2]) and 1 or 0"
KEY_SPACE_PREFIX = ' __keyspace@0__ :'
DEL_OR_EXPIRE_EVENTS = Set.new(['del', 'expired'])
def initialize(global_scope, max_lock_time)
# the global scope of this mutex (i.e "resource")
@global_scope = global_scope
# max time in seconds to hold the mutex
# (in case of greedy deadlock)
@max_lock_time = max_lock_time
end
def synchronise(local_scope = :global, &block)
# get the lock
acquire(local_scope)
begin
# execute the actions
return block.call
ensure
# release the lock
release(local_scope)
end
end
private
# attempt to acquire the lock
def acquire(local_scope = :global)
# construct the mutex key; the local scope
# of this mutex (i.e "resource_id")
mutex_key = "#{@global_scope}.#{local_scope}"
# while statement will either get the lock and
# set the expiry on the lock or do neither and return 0
while $conn_pool.with {|conn| conn.eval(LOCK_ACQUIRER, [mutex_key, @max_lock_time])} != 1 do
# wait and try again (until we can get in)
$subs_pool.with do |conn|
conn.subscribe("#{KEY_SPACE_PREFIX}#{mutex_key}") do |on|
on.subscribe do |channel, count|
# unsubscribe if the key was
# delete before we got here
key_exists = $conn_pool.with do |pool_conn|
pool_conn.exists(key_name)
end
conn.unsubscribe unless key_exists
end
on.message do |channel, message|
# unsubscribe if we get a del
# or expired event for the key
if DEL_OR_EXPIRE_EVENTS.include?(message)
conn.unsubscribe
end
end
end
end
end
end
# release the lock
def release(local_scope = :global)
# return value indicating whether the lock was currently held
mutex_key = "#{@global_scope}.#{local_scope}"
return $conn_pool.with {|conn| conn.del(mutex_key)} == 1
end
end
How to use it
Now, see the simple usage sample below (exactly the same as we did it before)
MY_MUTEX = RedisMutex.new('server_access', 10.seconds)
...
MY_MUTEX.synchronise(server.id) do
# do some stuff here that needs to be synchronised
# for this resource (across all application instances)
end
Conclusion
In this blog post, we took our previous implementation of a multithreading/cross process or server synchronization solution, and enhanced it for better throughput performance.
Happy coding!
- Check out part I - 'Ruby Mutex Mayhem'.