docs | |
---|---|
tests | |
package |
Lock context manager implemented via redis SETNX/BLPOP.
- Free software: BSD 2-Clause License
Interface targeted to be exactly like threading.Lock.
Because we don't want to require users to share the lock instance across processes you will have to give them names.
from redis import Redis
conn = Redis()
import redis_lock
lock = redis_lock.Lock(conn, "name-of-the-lock")
if lock.acquire(blocking=False):
print("Got the lock.")
lock.release()
else:
print("Someone else has the lock.")
conn = StrictRedis()
with redis_lock.Lock(conn, "name-of-the-lock"):
print("Got the lock. Doing some work ...")
time.sleep(5)
You can also associate an identifier along with the lock so that it can be retrieved later by the same process, or by a different one. This is useful in cases where the application needs to identify the lock owner (find out who currently owns the lock).
import socket
host_id = "owned-by-%s" % socket.gethostname()
lock = redis_lock.Lock(conn, "name-of-the-lock", id=host_id)
if lock.acquire(blocking=False):
assert lock.locked() is True
print("Got the lock.")
lock.release()
else:
if lock.get_owner_id() == host_id:
print("I already acquired this in another process.")
else:
print("The lock is held on another machine.")
The dogpile is also known as the thundering herd effect or cache stampede. Here's a pattern to avoid the problem without serving stale data. The work will be performed a single time and every client will wait for the fresh data.
To use this you will need django-redis, however, python-redis-lock
provides you a cache backend that has a cache method for your convenience. Just install python-redis-lock
like
this:
pip install "python-redis-lock[django]"
Now put something like this in your settings:
CACHES = {
'default': {
'BACKEND': 'redis_lock.django_cache.RedisCache',
'LOCATION': 'redis://127.0.0.1:6379/1',
'OPTIONS': {
'CLIENT_CLASS': 'django_redis.client.DefaultClient'
}
}
}
Note
If using a django-redis < 3.8.x, you'll probably need redis_cache which has been deprecated in favor to django_redis. The redis_cache module is removed in django-redis versions > 3.9.x. See django-redis notes.
This backend just adds a convenient .lock(name, expire=None)
function to django-redis's cache backend.
You would write your functions like this:
from django.core.cache import cache
def function():
val = cache.get(key)
if not val:
with cache.lock(key):
val = cache.get(key)
if not val:
# DO EXPENSIVE WORK
val = ...
cache.set(key, value)
return val
In some cases, the lock remains in redis forever (like a server blackout / redis or application crash / an unhandled exception). In such cases, the lock is not removed by restarting the application. One solution is to turn on the auto_renewal parameter in combination with expire to set a time-out on the lock, but let Lock() automatically keep resetting the expire time while your application code is executing:
# Get a lock with a 60-second lifetime but keep renewing it automatically
# to ensure the lock is held for as long as the Python process is running.
with redis_lock.Lock(conn, name='my-lock', expire=60, auto_renewal=True):
# Do work....
Another solution is to use the reset_all()
function when the application starts:
# On application start/restart
import redis_lock
redis_lock.reset_all()
Alternatively, you can reset individual locks via the reset
method.
Use these carefully, if you understand what you do.
- based on the standard SETNX recipe
- optional expiry
- optional timeout
- optional lock renewal (use a low expire but keep the lock active)
- no spinloops at acquire
redis_lock
will use 2 keys for each lock named <name>
:
lock:<name>
- a string value for the actual locklock-signal:<name>
- a list value for signaling the waiters when the lock is released
This is how it works:
https://python-redis-lock.readthedocs.io/en/latest/
To run the all tests run:
tox
OS: | Any |
---|---|
Runtime: | Python 2.7, 3.3 or later, or PyPy |
Services: | Redis 2.6.12 or later. |
- bbangert/retools - acquire does spinloop
- distributing-locking-python-and-redis - acquire does polling
- cezarsa/redis_lock - acquire does not block
- andymccurdy/redis-py - acquire does spinloop
- mpessas/python-redis-lock - blocks fine but no expiration
- brainix/pottery - acquire does spinloop