Distributed Lock

Giriş

Distributed Lock kullanmak için şu teknolojileri sarmalayan küçük kod örnekler burada.

Curator + Zookeeper

Cassandra

Hazelcast

JPA 

JPA için Pessimistic Lock kullanılabilir

MySQL

Bu yazıya bakabilirsiniz

Zookeeper

Zookeeper ve etcd örneği burada

Redis

Ayrıca bazı Redis kütüphaneleri Distributed Lock imkanı sunuyor. Açıklaması şöyle.

The most common way to ensure that there is only one process using a resource is to use a Distributed Lock.

There are several mechanisms you can use, here are some:

- AWS DynamoDB Lock Client

- Azure Blob Lease operation

- ZooKeeper Lock

- Redis Redlock

- Database based lock such as PotgreSQL Advisory Lock

- Spring kullanıyorsak RedisLockRegistry Sınıfı ve  @RedisLockable Anotasyonu yazısına bakabilirsiniz

- Jedis kullanıyorsak Jedis.setnx metodu yazısına bakabilirsiniz. Burada tek Redis sunucusu kullanılıyor

- Lettuce kullanıyorsak Redlock algoritması kullanılabilir. Burada fault-tolerance ve consensus için çok Redis sunucusu kullanılıyor

Redlock İçin Uyarı

Redlock kullanırken kilit belirli bir süre için alınıyor. Bu süre içinde kilit bırakılmazsa bir başkası olabilir ve Lost Update probleminin bir benzeri olabilir. Şeklen şöyle

Bu konuda bir yazı şöyle

When researching distributed locks, I stumbled upon a fascinating 10-year-old public debate between antirez (Redis creator) and Martin Kleppmann (author of DDIA book) about the safety and correctness of Redlock algorithm.

My oversimplified summary:

- antirez: Here's Redlock, a simple decentralised locking algorithm using multiple independent Redis instances that is safer than the single instance approach. Please provide feedback.

- Kleppmann: Here are a bunch of cases when due to GC pauses or network delays Redlock can fail. Please don't use Redlock if you need locks for correctness, use a consensus systems with fencing tokens instead. For efficiency optimisation, don't bother and just stick with the single-node locking.

- antirez: I'm sorry to have to say that but you've analysed the wrong implementation of the algorithm. You missed the clock check after lock acquisition. Pauses afterwards are a problem for any expiring lock. And I disagree that fencing tokens are always the answer.

- Klepmann: This is correct, I had overlooked that. But a pause afterwards or a delayed write can still outlive the lock. I stand by my conclusions.

Still no consensus but love this rabbit hole.

Links to the posts (post and HN comments are worth reading too):

- (antirez) Distributed Locks with Redis

- (Kleppmann) How to do distributed locking

- (antirez) Is Redlock safe?

SchedLock

ShedLock yazısına bakabilirsiniz. ShedLock kütüphanesi, distributed lock için veri tabanını kullanıyor.