Redis

Common Scenarios

Basic Data Structures

Deployment Approaches

Configuration Requirements

Implementing a Distributed Lock

Redis can implement a distributed lock with the SETNX (set if not exists) command. The steps are:

1. Define a key that names the lock, for example lock:my_lock.
2. Before acquiring the lock, set an expiry time so that a crashed client or a network fault does not leave the lock held forever. Use SETNX to set the value: if it returns 1, the set succeeded and the lock is acquired; if it returns 0, the lock is already held and acquisition failed.
3. If the lock was acquired, release it promptly after finishing the task by deleting the key with the DEL command.

A simple example:

def get_lock(conn, lock_name, expire_time=10):
    # try to acquire the lock
    is_locked = conn.setnx(lock_name, 'locked')
    if is_locked:
        # set the lock expiry
        conn.expire(lock_name, expire_time)
        return True
    else:
        return False

def release_lock(conn, lock_name):
    # release the lock
    conn.delete(lock_name)

When using a distributed lock, take network latency and lock granularity into account. And to avoid deadlock, set a sensible expiry and check on release that the lock is the one you hold.

Redis Key Expiry Mechanisms

Redis Key Eviction Policies

The stop the world Problem

Redis is a single-threaded in-memory database, meaning it uses one main thread to handle all client requests. Redis is designed around non-blocking IO, so some operations do not block the main thread. That avoids most "stop the world" problems.

However, some operations can still block the main thread. For example, commands such as BGSAVE, BGREWRITEAOF, FLUSHALL, and FLUSHDB perform a persistence operation that writes in-memory data to disk. During these operations the Redis main thread is blocked until the operation finishes. If the database is very large, this can take a while, causing a long pause.

Blocking can also occur when the main thread performs a lot of computation. For example, running a complex Lua script or a large set operation can occupy the main thread, so client requests cannot be answered promptly.

So while Redis avoids "stop the world" in most cases, it can still occur in some. To avoid it, Redis usage needs careful planning and tuning so that operations complete within acceptable time.

Competitor Analysis

powered by ChatGPT