Distributed Lock Implementations with Redis, Etcd, and Zookeeper

What is a distributed lock? A distributed lock coordinates access to shared resources across multiple processes or machines, ensuring mutual exclusion in high‑concurrency, high‑traffic environments where traditional single‑machine locking mechanisms fail.

Application scenarios

1. In monolithic single‑instance deployments, Java concurrency APIs can provide mutual exclusion.

2. In distributed systems, multiple JVMs require a cross‑process lock; distributed locks are used in high‑concurrency, high‑throughput situations.

Redis‑based distributed lock

The implementation uses Redisson. Key mechanisms include lock acquisition via a Lua script, re‑entrancy, a watchdog for automatic lease renewal, and lock release.

private RedissonClient getClient() {
    Config config = new Config();
    config.useSingleServer().setAddress("redis://127.0.0.1:6379");
    RedissonClient redissonClient = Redisson.create(config);
    return redissonClient;
}

private ExecutorService executorService = Executors.newCachedThreadPool();

@Test
public void test() throws Exception {
    int[] count = {0};
    for (int i = 0; i < 10; i++) {
        RedissonClient client = getClient();
        final RedisLock redisLock = new RedisLock(client, "lock_key");
        executorService.submit(() -> {
            try {
                redisLock.lock();
                count[0]++;
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                try { redisLock.unlock(); } catch (Exception e) { e.printStackTrace(); }
            }
        });
    }
    executorService.shutdown();
    executorService.awaitTermination(1, TimeUnit.HOURS);
    System.out.println(count[0]);
}

The RedLock algorithm creates three independent Redis instances and obtains a lock only when a majority (at least two) of them grant the lock, improving fault tolerance.

public static RLock create(String url, String key) {
    Config config = new Config();
    config.useSingleServer().setAddress(url);
    RedissonClient redissonClient = Redisson.create(config);
    return redissonClient.getLock(key);
}

RedissonRedLock redissonRedLock = new RedissonRedLock(
    create("redis://127.0.0.1:6379", "lock_key1"),
    create("redis://127.0.0.1:6380", "lock_key2"),
    create("redis://127.0.0.1:6381", "lock_key3")
);
RedisRedLock redLock = new RedisRedLock(redissonRedLock);

Etcd‑based distributed lock

Etcd provides a lease mechanism (TTL) to automatically release locks on failure, a revision number for ordering, a prefix mechanism for unique keys, and a watch mechanism to monitor predecessor keys, enabling a fair and reliable lock.

public class EtcdDistributeLock extends AbstractLock {
    private Client client;
    private Lock lockClient;
    private Lease leaseClient;
    private String lockKey;
    private String lockPath;
    private AtomicInteger lockCount;
    private Long leaseTTL;
    private ScheduledExecutorService service;
    private final ConcurrentMap<Thread, LockData> threadData = Maps.newConcurrentMap();
    // ... constructor and lock/unlock implementations using leaseClient.grant, lockClient.lock, watch, etc.
}

Test code demonstrates creating many threads that acquire the Etcd lock, perform a critical section, and release the lock.

public class EtcdLockTest {
    private Client client;
    private String key = "/etcd/lock";
    private ExecutorService executorService = Executors.newFixedThreadPool(10000);
    @Before
    public void before() throws Exception { initEtcdClient(); }
    private void initEtcdClient() { client = Client.builder().endpoints(server).build(); }
    @Test
    public void testEtcdDistributeLock() throws InterruptedException {
        int[] count = {0};
        for (int i = 0; i < 100; i++) {
            executorService.submit(() -> {
                EtcdDistributeLock lock = new EtcdDistributeLock(client, key, 20, TimeUnit.SECONDS);
                try { lock.lock(); count[0]++; } finally { lock.unlock(); }
            });
        }
        executorService.shutdown();
        executorService.awaitTermination(1, TimeUnit.HOURS);
        System.err.println("Result: " + count[0]);
    }
}

Zookeeper‑based distributed lock

The lock uses temporary sequential nodes; the client with the smallest node acquires the lock, while others watch the predecessor node to avoid the herd effect.

public class ZKLock extends AbstractLock {
    private CuratorFramework client;
    private InterProcessLock lock;
    public ZKLock(String zkAddress, String lockPath) {
        client = CuratorFrameworkFactory.newClient(zkAddress, new RetryNTimes(5, 5000));
        client.start();
        this.lock = new InterProcessMutex(client, lockPath);
    }
    @Override
    public void lock() { try { lock.acquire(); } catch (Exception e) { throw new RuntimeException(e); } }
    @Override
    public void unlock() { try { lock.release(); } catch (Exception e) { throw new RuntimeException(e); } }
}

Summary

1. Redis (single‑instance) locks can become a single point of failure; RedLock mitigates this by requiring a majority of three or more Redis nodes, at the cost of higher operational complexity.

2. Zookeeper locks are highly available and re‑entrant but incur higher latency due to frequent node creation/deletion.

3. Etcd locks combine the strengths of Zookeeper with improved performance, leveraging leases, revisions, prefixes, and watches to provide a fair, reliable, and fault‑tolerant distributed locking mechanism.