Is this repository still being maintained?

[christian-gama]

I wonder if this repository still actively maintained. I noticed last change happened more than 1 year ago and latest version is still 5.0.0-beta.2 since then.

Type definition for version 5 is missing as well.

If this is no longer maintained, is there an active repository for redlock implementation?

[rdadoune]

If you're using pnpm or yarn you can patch to get the typings to work (see my comment here). Hoping the maintainers haven't abandoned this project 🤞.

[punkpeye]

@mike-marcacci Would it be possible to release a patched version?

[ckane]

FWIW, on a project I contribute to, we are switching to this implementation: https://github.com/sesamecare/redlock

[abdullah230695]

If you're using pnpm or yarn you can patch to get the typings to work (see my comment here). Hoping the maintainers haven't abandoned this project 🤞.

can this be used without 'ioredis' ?

[punkpeye]

FWIW, on a project I contribute to, we are switching to this implementation: https://github.com/sesamecare/redlock

Appreciate you sharing this!

[ckane]

FWIW, on a project I contribute to, we are switching to this implementation: https://github.com/sesamecare/redlock

Appreciate you sharing this!

Anything for my fellow travelers

[smilecc]

I get some bad experiences while using this library, so I did some work, https://smilecc.github.io/node-redisson/

If anyone is willing to use it, it would be my honor.

[punkpeye]

What's the bad experience and what did you change?

I've been using it with no issues.

[ckane]

From The GitHub Page:

Why Node Redisson

Usually, Node.js developers will use Node Redlock as a distributed lock, but it seems that this project is no longer maintained.

Moreover, node-redlock project is not very easy to use. When using it, you need to pay great attention to the holding time of the lock, make predictions about the holding time of the lock in advance, and manually renew the lock. However, in actual business development, it is very difficult to make efficient predictions about the holding time of the lock.

Node Redisson has implemented the watchdog and unlock notification features, so that you don't have to worry about predicting the holding time of the lock anymore.

Of course, you can also manually set the duration of the lock.

[smilecc]

What's the bad experience and what did you change?

I've been using it with no issues.

First of all, I want to say that different solutions have different pros and cons, and I don't want to argue about this.

Let me talk about some of the shortcomings of the Redlock solution that I know of.

1. Redlock relies on N+1 nodes of Redis. When you use 3 or 5 nodes, it does cost more machines and operation costs.

2. Redlock uses voting to determine the ownership of the lock, which is very dependent on the clock consistency of multiple nodes. but the clock may jump. For example, we know that there are leap seconds in this world.

3. I roughly read the code of this repository. In redlock, since time is very important, in the article of antirez (the proposer of redlock), it is very important to judge the time consumed after acquiring the lock, but I don't seem to find such code.

How can ZooKeeper's lock avoid similar problems? In ZooKeeper, there is no need to consider the expiration time of the lock. It uses temporary nodes and uses the client heartbeat to ensure that the client can hold the lock after getting the lock until the lock is released or the connection is disconnected.

But I still want to use Redis, so Redisson implements a similar mechanism on the client side to realize the heartbeat of the lock.

That's all I want to say and what I do. If there are any errors, please point them out. Thank you.

[FabianFrank]

FWIW, on a project I contribute to, we are switching to this implementation: https://github.com/sesamecare/redlock

This appears to be a great drop in replacement