Distributed lock với Redis: implement như thế nào? Redlock algorithm giải quyết vấn đề gì?

Basic distributed lock:

# SET key value NX EX timeout (atomic: set only if not exists)
SET lock:resource unique_id NX EX 30

-- Release: Lua script để atomic check-and-delete
if redis.call('GET', KEYS[1]) == ARGV[1] then
  return redis.call('DEL', KEYS[1])
end

Vấn đề với single Redis instance: nếu Redis crash sau khi client A acquire lock nhưng trước khi expire, lock mất vĩnh viễn; nếu Redis failover sang replica, replica có thể chưa nhận lock → client B cũng acquire được lock → 2 clients cùng hold lock. Redlock (Martin Kleppmann cảnh báo vẫn không hoàn hảo): acquire lock trên N (>=5) independent Redis instance — phải là các host độc lập thực sự, không dùng chung persistence; lock chỉ valid khi acquire thành công trên majority (N/2+1) trong thời gian < lock validity.

• Kleppmann argue rằng nếu process bị pause dài hơn TTL (GC, network), client vẫn tin rằng đang hold lock trong khi lock đã expire và được acquire bởi client khác.
• Đây là thuật toán phức tạp, nhiều tranh cãi.
• Thực tế production: dùng Redlock cho non-critical locks (rate limiting, idempotency key); dùng ZooKeeper hoặc etcd cho critical distributed coordination.
• Library: ioredis + redlock npm package; Java Redisson.