How do I refresh a lock in redislock?

Use the Refresh method on the lock object, passing the context and new TTL duration. This is shown in the example where lock.Refresh extends the lock for another 100 milliseconds to prevent expiration during long tasks.

Does redislock automatically retry if a lock is not obtained?

No, it does not. The Obtain method is non-blocking and returns ErrNotObtained immediately. You need to implement your own retry logic with backoff, as suggested in the code comments for handling errors.

What's the difference between redislock and redsync?

redislock is simpler and more minimalistic, focusing on basic locking with a clean API, while redsync often includes features like multi-master support and might have broader community usage. Choose based on your need for simplicity versus advanced capabilities.

How to handle long-running tasks with redislock?

Periodically call the Refresh method to extend the lock's TTL while the task runs. Use the TTL method to check remaining time and refresh before expiration to maintain lock ownership and avoid race conditions.

Is redislock suitable for high-concurrency scenarios?

It can be, but performance depends on Redis latency and throughput. For very high concurrency, monitor Redis load and consider tuning, as each lock operation involves a network call to Redis, which could become a bottleneck.

What happens if Redis crashes while a lock is held?

The lock will expire based on its TTL, but until Redis recovers, lock state might be lost or inconsistent. Implement application-level checks or use Redis persistence features to mitigate risks, but there's no built-in recovery mechanism.

Open-Awesome

redis-lock

NOASSERTIONGo

A Go library providing a simplified distributed locking implementation using Redis.

GitHub

1.8k stars166 forks0 contributors

What is redis-lock?

redislock is a Go library that implements distributed locking using Redis as a backend. It solves the problem of coordinating access to shared resources across multiple processes or servers in a distributed system, preventing race conditions and ensuring mutual exclusion.

Target Audience

Go developers building distributed applications, microservices, or systems that require synchronization across multiple instances, such as job schedulers, resource managers, or critical section protectors.

Value Proposition

Developers choose redislock for its minimalistic and idiomatic Go API, reliability through Redis's persistence, and simplicity compared to rolling custom locking logic, making it a lightweight yet robust solution for distributed coordination.

Overview

Simplified distributed locking implementation using Redis

Use Cases

Best For

Implementing leader election in a cluster of Go services
Preventing duplicate processing of jobs in a distributed worker pool
Synchronizing access to shared external resources (e.g., databases, APIs)
Protecting critical sections in horizontally scaled applications
Ensuring only one instance runs a scheduled task at a time
Coordinating state changes across microservices in a transaction-like manner

Not Ideal For

Systems requiring reentrant locks or hierarchical locking structures
Applications where Redis network latency is a critical performance bottleneck
Projects needing out-of-the-box automatic retry with configurable backoff strategies
Environments without reliable Redis infrastructure or where Redis is a single point of failure

Pros & Cons

Pros

Simple Clean API

Offers intuitive functions like Obtain, Release, Refresh, and TTL, as shown in the example code, making integration straightforward without complex configuration.

Automatic Expiration Safety

Locks have a built-in TTL to prevent deadlocks from stale locks, and methods like TTL and Refresh allow for safe management in long-running operations.

Non-blocking Acquisition

The Obtain method returns immediately with an error if the lock is unavailable, enabling efficient error handling without blocking, as demonstrated in the example.

Cons

No Built-in Retry Logic

Default acquisition has zero backoff retries, requiring developers to manually implement retry loops, as indicated in the example where ErrNotObtained leads to immediate return.

Redis Dependency Risks

Locks rely entirely on Redis availability; any downtime or network issues can cause lock failures, making the system vulnerable without additional fault tolerance.

Limited Advanced Features

Focuses on simplicity, so it lacks support for reentrant locks, fair locking, or multi-master Redis setups, which might be necessary for complex distributed systems.

Frequently Asked Questions

Related Projects

Go-zero

A cloud-native Go microservices framework with cli tool for productivity.

A standard library for microservices.

Stars27,431

Forks2,444

Last commit2 years ago

Kratos

Your ultimate Go microservices framework for the cloud-native era.

Stars25,803

Forks4,168

Last commit23 days ago

grpc-go

The Go language implementation of gRPC. HTTP/2 based RPC

Stars23,013

Forks4,725