[Redis] 분산락을 깊게 다뤄보자. (RedLock, Redisson)

🧐 들어가기전

Redis에 대한 개념을 되짚어보다가, 분산락을 다시 한 번 살펴보게 되었고 문득 다음과 같은 궁금증이 생기게 되었다.
 
"분산락은 어떤 구조로 이루어져있지? 우리가 흔하게 쓰는 Redisson의 내부구조는 어떻게 생겼지?"
 
"분산락은 비관락과 어떤 차이점을 지니고 있고 어떤 장단점을 취하고 있지? 주의해야할 부분이 뭘까?"
 
"분산락은 내부적으로 스핀락 형태를 취하고 있는가? 아니면 뮤텍스의 형태를 취하고 있는가? 아니면 세마포어?"
 
이 고민들을 해결하기 위해 해당 포스팅에서는 레디스 분산락을 깊게 다뤄볼 예정이다.

---

🔸 1. Redis 분산락의 기본 구조

분산 시스템에서는 하나의 자원을 여러 서버 또는 프로세스가 동시에 접근하려고 할 때 경쟁 조건(race condition) 이 발생할 수 있다. 이를 해결하기 위해 필요한 것이 바로 분산락이다.

1️⃣ 분산락 vs 비관락?

여기서 한 가지 의문이 생긴다.

"비관락은 분산 시스템에서 사용할 수 없는 것인가?"

 
비관락은 주로 데이터베이스 수준에서 적용되는 테이블 단위의 락이다. 단일 DB 인스턴스에서라면 트랜잭션 기반의 락을 통해 정합성을 보장할 수 있다. 하지만 분산 시스템의 경우에는 이야기가 달라진다. 아래의 그림을 통해 자세히 살펴보자.

🔹1. 단일 DB 인스턴스

 
 

만약 위와 같이 쓰기 DB 대상이 하나인 경우에는 테이블 단위의 락인 비관락을 걸어도 데이터의 정합성을 지킬 수 있다.
 

🔹2. 분산 환경

하지만 분산 환경에서는 DB 인스턴스가 여러 개로 나뉘게 되며, 이 경우 비관락만으로는 데이터 정합성을 지키기 어려워진다.하지만 DB의 레플리카가 많아지는 경우, 사용자 요청이 락이 걸리지 않은 다른 노드로 전달될 수 있는 상황이 발생하게 된다.
이로 인해 특정 노드에서는 락이 걸려있지만, 다른 노드에서는 락이 적용되지 않은 상태로 쓰기 작업이 이루어지는 등 데이터 불일치 현상이 발생할 수 있다.

결국, 분산 환경에서 비관락은 한계가 있으며, 중앙에서 락 상태를 관리하고 일관된 제어가 가능한 분산락 방식이 보다 적절한 선택이 되는 것이다.
 

💡분산락은 다양한 경우에 사용이 가능하다!

분산락은 반드시 쓰기 DB가 여러 개 있는 경우에만 필요한 것은 아니다.
 
앞서 살펴본 것처럼, 분산락은 중앙의 Redis가 락 획득 여부를 관리하며 동작하고 DB 수준에서 실행되는 락이 아니기 때문에 꼭 데이터베이스가 아니더라도 파일, 메시지 큐, 캐시 등 다양한 자원에 적용할 수 있다. 즉, 시스템 내에서 자원을 공유하거나 접근 경쟁이 발생하는 거의 모든 상황에서 분산락은 유효하게 사용될 수 있다.
 
또한 분산락은 데이터베이스에 도달하기 이전, 즉 비즈니스 로직 단에서 선제적으로 락을 제어할 수 있다는 점에서 유연성과 효율성 측면에서도 매우 강력한 도구가 된다.
 
이러한 특성 덕분에, 복잡한 동시성 제어나 중복 요청 방지 등 다양한 실무 시나리오에서 널리 활용된다.

---

2️⃣ Redis Lock 내부 명령어

SET mylock unique_id NX PX 3000

Redis에서 가장 기본적인 분산락은 SET 명령 하나로 구현된다.
 

• NX : 키가 존재하지 않을 때만 설정 (누군가가 키를 가지고 있다면 실패한다.)
• PX 3000 : 락의 만료시간을 밀리초 단위로 설정 (여기선 3초)

여기서의 핵심은 NX이다.
 

NX라는 옵션을 줌으로써 누군가가 mylock이라는 이름으로 키를 가지고 있으면 키를 생성할 수 없고, 누군가가 키를 가지지 않았다면 mylock이라는 이름으로 키를 생성하는 구조이다.
 
그렇다면 이제 경쟁 자원에서 원하는 해당 작업을 치르고 난 후에는 락을 풀어야한다.

DEL mylock

이때는 DEL 명령어를 통해서 키를 삭제해주면 된다.
 
하지만 이렇게 되면 문제가 발생한다.

"아무나 키를 제거할 수 있는거 아닌가? 키를 획득한 주체만 제거하도록 강제해야하는 것 아닌가?"

 
 
따라서 두 가지의 조건을 만족해야 키를 제거할 수 있도록 설정해야한다.

1. 키가 존재해야한다.
2. 값이 일치해야한다. (이때 값은 UUID와 같은 고유랜덤값으로 설정하여 키를 설정한 클라이언트만 해당 값을 알 수 있도록 해야한다.)

위와 같은 조건을 적용하기 위해서는 아래와 같은 Lua 스크립트를 통해 삭제할 것을 권고한다.

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

---

3️⃣ Redis의 구조적 한계

🚨Redis가 단일 리소스라면?

만약 Redis가 단일 리소스라면 위와 같이 Lua 스크립트를 통해 락을 해제하는 방식은 단일 장애 지점이 될 수 있다. 만약 하나의 레디스 자원을 의존하여 락을 걸고 공유 자원을 쓰기 작업을 실행하다가 해당 레디스가 장애가 일어난 경우에 대해서는 락에 대한 주도권을 잃어버릴 뿐만 아니라 공유자원에 대한 락을 걸 수 없는 상황이 된다.
 

🧐그러면 Redis를 여러 개 두면 되겠네~

따라서 Master-slave방식의 복제 구조를 생각해볼 수 있다. Redis는 자동으로 fail over를 제공하기에 master가 죽은 경우 slave가 자동으로 master로 승격하게 되며 위의 문제를 해결할 수 있을 것처럼 보인다.
 

하지만 복제 구조가 비동기이기 때문에 위와 같은 상황이 발생할 수 있다.

1. Client A가 Master에게서 mylock을 획득하였다.
2. 키에 대한 쓰기가 복제본으로 전송되기 전 Master가 다운된다.
3. 해당 키를 받지 못한 Slave가 Master로 승격한다.
4. Client B가 Master에게 mylock key를 요청하면 획득할 수 있다.

이러한 문제를 해결하기 위해 RedLock이 등장하게 된다.

---

🔸2. RedLock의 구조

위와 같은 문제를 해결하기 위해 레디스에서는 RedLock 알고리즘을 제안하였다. RedLock은 N대의 Redis 서버가 있다고 가정할 때, 과반 수 이상의 노드에서 Lock을 획득했다면 Lock을 획득한 것으로 간주한다. 그리고 이런식의 consensus를 거치려면 기본적으로 2n+1개의 노드를 가지고 있어야한다.

자바 진영에서는 이러한 RedLock이 Redisson을 통해 구현이 되어있다.
 

1️⃣ RedLock의 동작 원리

🔹1. 현재 시간을 밀리초 단위로 측정한다.

락 획득 시도를 시작하기 전에 System.currentTimeMillis()와 같은 방식으로 현재 시각을 밀리초(ms) 단위로 측정한다. 이 값은 락을 얻기 위해 소요된 시간을 계산하는 데 사용된다.

🔹2. N대의 Redis 서버에 순차적으로 락을 요청한다.

RedLock은 N대의 Redis 노드가 존재한다고 가정한다. 예를 들어 5대의 서버가 있다고 하자.
클라이언트는 각 Redis 서버에 SET mylock my_unique_value NX PX 10000 와 같은 형식으로 락 요청을 보낸다.
 
이때 중요한 점은 각 요청에 대해 짧은 timeout을 설정해야 한다는 것이다.
예를 들어, 전체 락 유효시간이 10초라면 각 Redis 서버에 대한 timeout은 5~50ms 수준으로 작게 설정한다.

이렇게 설정하는 이유는, 특정 Redis 서버가 장애 상태일 경우 해당 서버와의 통신으로 과도한 시간이 지체되는 것을 방지하기 위함이다.

🔹3. 과반수 이상의 서버로부터 락을 획득한다.

클라이언트는 Redis 서버들로부터 응답을 받은 후, 락을 성공적으로 획득한 서버의 개수를 집계한다. 예를 들어 총 5대의 Redis 서버 중 3대 이상(과반수)에서 락을 획득한 경우, 이는 락 획득에 성공한 것으로 간주한다.
 
단, 여기에는 한 가지 추가 조건이 있다.
 
락 획득에 소요된 시간이 유효시간보다 작아야 한다.
 
락 요청을 시작한 시점과 모든 응답을 받은 시점 사이의 총 소요 시간(T_elapsed)을 측정하고, 이 값이 락의 유효시간(TTL)보다 작아야 한다.
즉, 다음 조건이 동시에 만족해야 한다:

• 과반수의 Redis 노드에서 락을 획득
• 락을 획득하는 데 걸린 시간이 TTL보다 짧음

TTL이 10초인데 락을 획득하는 데 11초가 걸렸다면, 이미 락이 만료될 가능성이 있어 락 획득은 실패한 것으로 간주한다.

🔹4. 락의 실제 유효시간은 남은 시간으로 계산한다.

유효시간 = TTL - T_elapsed

락을 성공적으로 획득했다면, 실제로 사용 가능한 시간은 위와 같다.
즉, TTL이 10초이고 락을 얻는 데 3초가 걸렸다면, 락은 남은 7초 동안만 유효하다. 따라서 락을 사용하는 작업은 해당 시간 안에 완료되어야 한다.

🔹5. 락 획득에 실패했다면, 모든 서버에 락 해제를 요청한다.

과반수 락 획득에 실패했거나 TTL을 초과한 경우, 락 획득은 실패한 것으로 간주한다. 이때, 클라이언트는 락 획득에 성공한 Redis 서버들에 대해 락 해제 요청을 전송한다.

• 이는 일관성을 보장하고 락 잔류를 방지하기 위한 조치이다.
• 락 해제 시에는 클라이언트가 설정한 고유 식별자(UUID)를 사용하여, 자신이 설정한 락만 해제하도록 해야 한다.

---

2️⃣ 과반수 이상의 락을 획득했을 때 락을 획득하지 못한 노드는?

위와 같은 흐름에 따르면 Client 1이 3개의 노드로부터 락을 획득하게 되면 과반수 이상의 락을 획득한 것이므로, 락을 획득한 것으로 간주된다. 하지만 그렇게 되는 경우는 Node 2와 Node 4에 대해서는 락을 획득할 수 없는 상태이다.
 
그러면 이 실패한 2개의 노드에 대해서는 어떻게 처리될까?
 
실패한 노드는 아무 일도 하지 않는다.
락이 설정되지 않은 채 남아있어도 추후에 들어오는 락 요청에 대해서 같은 방식으로 동작하기에 절대로 과반수를 넘을 수 없기 때문이다.

위의 그림과 같이 Client 1이 락을 점유하고 있는 동안 Client 2가 락을 요청한다고 가정해보자.
그렇다면 이미 점유되어있는 Node 1, Node 2, Node 3에 대해서는 락을 획득하지 못하고 Node 2와 Node 4에 대해서만 락을 획득할 수 있다. 하지만 두 개의 노드는 과반수가 아니므로 락을 획득하지 않는 것으로 간주된다. 그리고 락을 획득하지 못함을 전달받은 Client는 절차에 따라 Lua Script로 락을 해제하는 절차를 밟는다.
 
이와 같은 이유로 락을 보장받을 수 있는 것이다.

---

🔸3. RedLock 한계

RedLodck 알고리즘은 실무에서 완전한 분산 합의 프로토콜이 아니며, 몇 가지 구조적 한계와 위험성을 안고 있다.
RedLock의 구조적 한계를 CAP 이론과 연관지어서 다뤄보고자한다.

1️⃣ 먼저, CAP 이론이란?

CAP 이론은 분산 시스템에서 세 가지 특성 중 동시에 두 가지만 만족할 수 있다는 이론이다.

C (Consistency)	모든 노드가 같은 데이터를 갖고 있다는 일관성
A (Availability)	모든 요청에 대해 응답을 반환할 수 있는 가용성
P (Partition tolerance)	네트워크 분할 상황에서도 시스템이 계속 동작할 수 있음

분산 환경에서는 P는 기본 전제로 받아들여야 하므로, 실제 선택지는 C와 A 중 하나를 선택하게 된다.

 

RedLock은 어떤 시스템에 가까운가?

• P (Partition Tolerance) : 허용
  → 네트워크 분할이 발생해도 동작 가능해야 한다.
• A (Availability) : 우선시
  → 락 요청을 빠르게 처리하기 위해 과반수 응답만으로 성공 판단
• C (Consistency) : 부분적으로만 보장
  → 이론상 TTL과 UUID 등으로 최소한의 일관성 유지하지만, 강한 일관성은 보장하지 못함

즉 RedLock은 CAP 이론상 AP 시스템에 가깝다.
 
하지만 여기서 문제가 생기는 이유가 바로 분산락은 본질적으로 데이터 보호, 동시성 제어, 무결성 보장을 위한 수단이라는 점이다.
따라서 락 시스템은 일반적인 데이터 저장소보다 일관성(C)을 훨씬 더 중시해야 하는데 여기서 모순이 발생하는 것이다.

---

2️⃣ RedLock의 주요 한계

🔹1. 강한 일관성(C)를 보장하지 못한다

레디스가 강한 일관성을 보장받지 못하는 다음과 같은 두 가지 case가 있다.

• Clock Drift로 인한 일관성 붕괴
• 애플리케이션 중단/GC로 인한 문제

[Clock Drift로 인한 일관성 붕괴]

RedLock은 노드 간의 시계가 완전히 동기화되어 있다는 가정 없이, 각 노드의 로컬 시간을 기준으로 TTL을 계산한다. 하지만 실제 환경에서는 시계가 동일한 속도로 흐르지 않으며, 이를 Clock Drift 라고 부른다.
 

1. 클라이언트 1이 Redis 노드 A, B, C에서 락을 획득한다.
2. 네트워크 문제로 D, E에서는 락을 획득하지 못한다.
3. 이때 노드 C의 시계가 비정상적으로 빨라진다 → TTL이 빨리 끝났다고 잘못 판단
4. 클라이언트 2가 뒤이어 노드 C, D, E에서 락을 획득한다. (C는 TTL 만료로 인해 락이 없다고 판단)
5. A와 B에서는 여전히 클라이언트 1의 락이 살아있다.
6. 결과적으로 클라이언트 1과 2가 동시에 락을 소유하고 있다고 착각하게 된다.
7. 두 클라이언트가 동일 자원에 동시 작업을 수행하면서 일관성 붕괴

 
 

[애플리케이션 중단/GC로 인한 문제]

RedLock은 락을 잡고 일정 시간 안에 작업이 완료될 것이라 가정한다.
하지만 현실에서는 클라이언트 측에서 예상치 못한 중단, GC(Garbage Collection), 프로세스 정지, 네트워크 지연 등의 이유로 작업이 지연될 수 있다.

function writeData(filename, data) {
  var lock = lockService.acquireLock(filename);
  if (!lock) {
    throw 'Failed to acquire lock';
  }

  try {
    var file = storage.readFile(filename);
    var updated = updateContents(file, data);
    storage.writeFile(filename, updated);
  } finally {
    lock.release();
  }
}

위의 코드는 락을 획득하고 파일을 저장하는 코드이다.
위 코드에서 발생할 수 있는 시나리오는 아래와 같다.

1. 클라이언트 1이 락을 획득하고 파일을 읽는다.
2. 이때 stop-the-world GC 또는 프로세스 중단으로 클라이언트 1이 멈춘다.
3. 락은 TTL 만료로 인해 Redis에서 자동으로 해제된다.
4. 클라이언트 2가 새로운 락을 획득하고 파일을 수정한 뒤 저장한다.
5. 클라이언트 1이 복구되어 멈춘 시점 이후의 파일 상태를 모른 채 다시 저장한다.
6. 결과적으로 클라이언트 2의 변경사항이 클라이언트 1에 의해 덮여써진다.

 
일반적으로 GC의 시간은 매우 짧아 위와 같은 상황이 발생하는 경우는 극히 드물다. 하지만 GC 이외에도 네트워크 지연이나 timing 이슈와 같은 문제로 위와 비슷한 상황이 발생할 수 있다. 이를 해결하기 위해서는 펜싱토큰과 같이 버전을 명시하는 토큰을 도입함으로써 해결할 수 있다. 낙관락과 비슷한 메커니즘으로 동작한다.

펜싱 토큰은 위와 같이 버전명을 명시함으로써 이후에 client 2가 쓰기를 진행하였을 때 해당 토큰의 version이 더 높으므로 추후에 들어오는 Client1의 토큰에 대해서는 reject할 수 있는 방식이다.
 
하지만 RedLock은 펜싱 토큰 기능을 제공하지 않는다. 펜싱 토큰을 도입하려면, 락을 획득할 때마다 증가하는 Global Counter가 필요하다. 이를 위해서는 노드 간의 값을 동기화할 수 있는 합의 알고리즘이 전제되어야 한다. 그러나 RedLock은 이러한 동기화 수단을 갖추고 있지 않으며, 결국 전역 카운터를 구성할 방법이 없다. 그렇다고 하나의 Redis 인스턴스에 카운터를 구현한다면, 이는 단일 장애 지점(SPOF)이 되어 시스템 전체의 안정성을 해칠 수 있다.
 
결국 RedLock은 강한 일관성을 보장받지 못하는 것이다. 
 

🔹2. 리더 노드나 중앙 합의 메커니즘이 없다

RedLock은 Paxos, Raft처럼 리더 선출, 로그 합의 등을 하지 않는다.
(위에서 보았던 것처럼 락을 획득하지 못한 노드에 대해서는 별다른 조치를 취하지 않는다.)
 
단순히 다수 노드의 응답만으로 "락을 잡았다"고 판단하는 구조다.
따라서 노드 간 상태 전파, 커밋 확정, 롤백이 없기 때문에 강력한 트랜잭션 수준의 락 합의에는 미치지 못한다

---

🔸4. 분산락은 스핀락, 뮤텍스, 세마포어?

Redis를 활용한 분산락 구현 방식은 다양한 클라이언트를 통해 가능하지만, 일반적으로 많이 사용되는 대표적인 클라이언트는 다음 두 가지이다.

• Lettuce: 저수준 Redis 클라이언트로, 분산락을 직접 구현해야 함
• Redisson: 고수준 추상화를 제공하는 라이브러리로, 락 관련 기능이 내장되어 있음

1️⃣ Lettuce를 활용한 Lock

🔹LettuceConfig.kt

@Configuration
class LettuceConfig(
    private val redisProperties: RedisProperties
) {

    @Bean
    fun redisConnectionFactory(): RedisConnectionFactory {
        val config = RedisStandaloneConfiguration(redisProperties.host, redisProperties.port)
        config.password = RedisPassword.of(redisProperties.password)
        return LettuceConnectionFactory(config)
    }

    @Bean
    fun redisTemplate(connectionFactory: RedisConnectionFactory): RedisTemplate<String, String> {
        val template = RedisTemplate<String, String>()
        template.setConnectionFactory(connectionFactory)
        template.keySerializer = StringRedisSerializer()
        template.valueSerializer = StringRedisSerializer()
        return template
    }

    @Bean
    fun stringRedisTemplate(connectionFactory: RedisConnectionFactory): StringRedisTemplate {
        val template = StringRedisTemplate()
        template.setConnectionFactory(connectionFactory)
        template.keySerializer = StringRedisSerializer()
        template.valueSerializer = StringRedisSerializer()
        return template
    }
}

 

🔹RedisLockRepository.kt (v1)

@Component
class RedisLockRepository(
    private val redisTemplate: RedisTemplate<String, String>
) {

    /**
     * SETNX + PX 로 락 획득 시도
     */
    fun lock(key: String, timeoutMillis: Long): Boolean {
        return redisTemplate
            .opsForValue()
            .setIfAbsent(key, "LOCK", Duration.ofMillis(timeoutMillis)) ?: false
    }

    /**
     * 단순 DEL 명령으로 락 해제
     */
    fun unlock(key: String): Boolean {
        return redisTemplate.delete(key)
    }
}

위와 같이 Lettuce의 경우에는 직접 lock 메서드와 unlock 메서드를 구현해야한다.
 
위의 코드처럼 단순히 DEL 명령어를 사용하여 락을 해제하는 방식으로 구현할 수 있지만, 이 방식은 락을 소유하지 않은 클라이언트가 락을 해제할 수 있는 위험이 있어 치명적이다.

🔹RedisLockRepository.kt (v2)

@Component
class RedisLockRepository(
    private val redisTemplate: RedisTemplate<String, String>
) {
    private lateinit var unlockScript: DefaultRedisScript<Long>
    private val lockExpiration = Duration.ofSeconds(10)
    private val lockPrefix = "LOCK:"

    @PostConstruct
    fun init() {
        // Lua 스크립트: 소유자(UUID)가 일치할 때만 락 해제
        unlockScript = DefaultRedisScript<Long>().apply {
            scriptText = """
                if redis.call("get", KEYS[1]) == ARGV[1] then
                    return redis.call("del", KEYS[1])
                else
                    return 0
                end
            """.trimIndent()
            resultType = Long::class.java
        }
    }

    /**
     * UUID를 포함한 락 획득
     * @param key 락 키
     * @param uuid 클라이언트 고유 ID
     */
    fun tryLock(key: String, uuid: String): Boolean {
        return redisTemplate
            .opsForValue()
            .setIfAbsent(lockPrefix + key, uuid, lockExpiration) ?: false
    }

    /**
     * Lua 스크립트로 안전하게 락 해제
     */
    fun releaseLock(key: String, uuid: String) {
        redisTemplate.execute(
            unlockScript,
            listOf(lockPrefix + key),
            uuid
        )
    }
}

따라서 보다 안전한 방법으로 락을 설정할 때 고유 식별자(UUID)를 함께 저장하고,
해제 시 Lua 스크립트를 통해 해당 UUID가 일치할 경우에만 락을 해제하는 방식으로 대체할 수 있다.
 

🧐 스핀락을 통한 락 획득

@Service
class GroupLettuceService(
    private val redisLockRepository: RedisLockRepository,
    private val gatherService: GatherService
) {

    fun join(groupId: Long, userId: Long) {
        val key = groupId.toString()
        val uuid = UUID.randomUUID().toString()

        while (!redisLockRepository.tryLock(key, uuid)) {
            Thread.sleep(100)
        }

        try {
            gatherService.join(groupId, userId)
        } finally {
            redisLockRepository.releaseLock(key, uuid)
        }
    }
}

Lettuce를 통한 락 획득 시도 로직은 위와 같고 위의 로직을 통해 락을 얻는 방식이 spin lock의 형태임을 알 수 있다.
락을 획득하지 못한 경우, 일정 시간 간격으로 계속 Redis에 락 획득 요청을 보내는 방식이며 락이 성공할 때까지 이 과정을 반복하게 된다.

하지만 위와 같은 단순한 spin lock의 방식은 락을 획득하지 못한 경우, 락이 풀릴 때까지 Redis에 반복적으로 while 루프로 요청을 보내야 하며 이 과정에서 스레드는 계속 깨어 있는 상태로 CPU를 사용하게 된다.
특히 Redis는 싱글 스레드로 동작하기 때문에, 락 획득을 위한 반복 요청이 많아질수록 Redis 자체에 부하가 쌓이게 되고 이는 전체 처리 성능 저하로 이어질 수 있다.

즉, 단순 구현은 가능하지만, 락 경합이 많은 상황에서는 Redis와 애플리케이션 모두에 부담을 줄 수 있는 방식이다.

---

2️⃣ Redisson을 활용한 Lock

Lettuce에서는 분산락을 개발자가 직접 구현해야 하지만, Redisson은 분산락 기능을 고수준으로 추상화하여 제공한다.
따라서 락 획득, 해제, 자동 연장 등 복잡한 로직을 직접 작성할 필요 없이 간단한 API 호출만으로 분산락을 사용할 수 있다.
 

https://github.com/redisson/redisson/blob/master/redisson/src/main/java/org/redisson/api/RLock.java?utm_source=chatgpt.com

Redisson에서는 RLock이라는 분산 락 객체 인터페이스를 제공해준다.
그리고 락을 거는 구현체로는 tryLock()을 제공하는 것을 살펴볼 수 있다. 

이때 tryLock을 구현하는 클래스를 살펴보 다음과 같은 세 가지의 클래스가 있음을 확인하였다.

• RedissonLock
• RedissonMultiLock
• RedissonSpinLock

각각의 방식에 대해 알아보자.

---

🔹RedissonLock

redisson/redisson/src/main/java/org/redisson/RedissonLock.java at master · redisson/redisson

 

[ 메서드 시그니처 ]

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException

• waitTime: 락을 얻기 위해 최대 기다릴 시간
• leaseTime: 락을 점유할 수 있는 시간 (자동으로 해제됨)
• unit: 시간 단위
• 반환값: 락 획득 여부

[ 시간 계산 ]

long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
long threadId = Thread.currentThread().getId();

타임아웃 계산을 위한 시작 시간과 thread ID 설정한다.

 
[ 락 획득 시도 ]

Long ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId);
if (ttl == null) {
    return true;
}

위의 로직을 살펴보면 tryAcquire() 메서드를 호출하는 것을 살펴볼 수 있다.

private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return (Long)this.get(this.tryAcquireAsync(waitTime, leaseTime, unit, threadId));
}

그리고 tryAcquire()메서드는 내부적으로 tryAcquireAsync()를 호출한다.

그리고 tryAcquireAsync()는 비동기적으로 tryLockInnerAsync()를 호출하는 것을 살펴볼 수 있다.

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    return this.evalWriteAsync(this.getRawName(),
    LongCodec.INSTANCE, command,
    "if ((redis.call('exists', KEYS[1]) == 0) or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return redis.call('pttl', KEYS[1]);", Collections.singletonList(this.getRawName()), new Object[]{unit.toMillis(leaseTime), this.getLockName(threadId)});
}

이때, tryLockIntterAsync()는 내부적으로 Lua Script를 호출하여 Lock을 획득하는 로직을 작성한 것을 살펴볼 수 있다.

Redisson은 Netty 기반의 비동기 네트워크 클라이언트이기 때문에,
Redis에 락 요청을 보낼 때 블로킹 없이 요청을 날리고, 결과가 돌아오면 콜백 기반으로 후처리를 진행한다..

 
[ Pub/Sub 구독 (락 해제 이벤트 대기) ]

CompletableFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId);

락 해제 이벤트가 Redis 채널을 통해 publish되면 이를 수신하기 위해 락 채널을 구독하는 것을 살펴볼 수 있다.

이때 subscribe() 메서드를 조금 더 자세히 살펴보면 threadId로 구독하는 것을 살펴볼 수 있고, 구독 해제 이벤트에 대해 내부적으로 세마포어에서 동시성 제어를 하는 것을 살펴볼 수 있다.
 
이때, 세마포어의 역할은 다음과 같다.

• 하나의 Pub/Sub 채널에 대해 동시에 너무 많은 구독을 생성하지 않도록 동시성 제어
• 한 번에 하나의 스레드만 Redis에 SUBSCRIBE 요청을 날릴 수 있도록 제한
• Redis에 중복 구독 요청을 보내는걸 방지 → 기존 구독이 있다면 재사용

[ TTL 내에 락 재시도 루프 ]

do {
    long currentTime = System.currentTimeMillis();
    ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId);

    if (ttl == null) {
        return true;
    }

    time -= System.currentTimeMillis() - currentTime;
    if (time <= 0L) {
        this.acquireFailed(waitTime, unit, threadId);
        return false;
    }

    if (ttl >= 0L && ttl < time) {
        entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
    } else {
        entry.getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
    }

    time -= System.currentTimeMillis() - currentTime;
} while (time > 0L);

 

• 락을 아직 얻지 못했다면 TTL만큼 tryAcquire() 반복
• Redis 채널에서 락 해제 이벤트 수신 시, 대기 중인 스레드가 깨어나 다시 락을 시도
• 타임아웃 내에서 반복 시도

[ 구독 해제 ]

this.unsubscribe((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture), threadId);

락을 획득하거나 실패 시 구독 해제하는 것을 볼 수 있다.

---

정리하자면, 다음과 같이 Redisson Lock은 내부적으로 세마포어 기반 Pub/Sub으로 동작하는 것을 살펴볼 수 있다.
 

• 락 시도
  • Redis에 직접 Lua 스크립트로 락 획득 시도 (SETNX + TTL 등)
  • 실패 시 → Redis 채널을 구독해서 락 해제 알림을 기다림
• 구독 처리 (subscribe)
  • RedissonLock은 내부적으로 LockPubSub을 통해 Redis Pub/Sub 채널을 구독
  • 이때 AsyncSemaphore로 중복 구독을 방지
    • 즉, 하나의 채널당 하나의 연결만 SUBSCRIBE 하도록 세마포어로 보호
• 해당 채널에서 락 해제 알림 수신 시 → 다시 tryLock 시도
  • 락을 잡은 클라이언트가 unlock() 하면 Redis 채널에 "UNLOCK" 메시지 발행
  • 다른 대기 중 클라이언트들은 이 메시지를 구독 중이므로 알림 받고 락 재시도

---

 

🔹RedissonMultiLock

redisson/redisson/src/main/java/org/redisson/RedissonMultiLock.java at master · redisson/redisson

RedissonMultiLock은 여러 개의 RLock을 동시에 획득하여, 모두 성공해야 하나의 락으로 간주하는 멀티락 구현이다.

 

[ 메서드 시그니처 ]

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit)

• waitTime: 락을 얻기 위해 최대 기다릴 시간
• leaseTime: 락을 점유할 수 있는 시간 (자동으로 해제됨)
• unit: 시간 단위
• 반환값: 락 획득 여부

[ 락 획득 시도 루프 시작 ]

List<RLock> acquiredLocks = new ArrayList(this.locks.size());
ListIterator<RLock> iterator = this.locks.listIterator();

순차적으로 모든 락 획득을 시도하며 성공한 락은 리스트에 저장한다.

 
[ 각 RLock에 대해 tryLock 시도 ]

boolean lockAcquired = lock.tryLock(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS);

내부적으로 여러 개의 RedissonLock을 가지고, 각 락에 대해 개별적으로 tryLock()을 순차 시도한다.

if (!lockAcquired) {
    if (this.locks.size() - acquiredLocks.size() == this.failedLocksLimit()) {
        break; // 실패 허용 개수 초과
    }

    if (failedLocksLimit == 0) {
        this.unlockInner(acquiredLocks); // 지금까지 획득한 락 전부 해제
        if (waitTime <= 0L) return false;

        failedLocksLimit = this.failedLocksLimit();
        acquiredLocks.clear();
        iterator = this.locks.listIterator(); // 처음부터 다시 시도
    } else {
        --failedLocksLimit;
    }
}

앞서 다룬 Lock과 해당 Lock 로직의 차이점은 위와 같다.

• 하나의 락이라도 실패하면 전체 롤백
• 실패 허용 범위 초과 시 반복 종료
• 아니면 전부 해제 후 다시 처음부터 시도

---

정리하자면,

1. 여러 개의 RLock을 순차적으로 tryLock() 시도
2. 하나라도 실패하면 획득한 모든 락을 해제
3. 남은 시간 계산 후 다시 처음부터 재시도
4. 이 과정을 waitTime이 소진될 때까지 반복

 
RedissonMultilLock은 여러 개의 RLock 인스턴스를 묶어서, 모두 동시에 락을 걸 수 있을 때만 성공하는 구조이다.
또한 내부적으로 Pub/Sub의 방식이 아닌 Spin Lock의 형태를 취하고 있다.

---

🔹RedissonSpinLock

redisson/redisson/src/main/java/org/redisson/RedissonSpinLock.java at master · redisson/redisson

[ 메서드 시그니처 ]

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit)

• waitTime: 락을 얻기 위해 최대 기다릴 시간
• leaseTime: 락을 점유할 수 있는 시간 (자동으로 해제됨)
• unit: 시간 단위
• 반환값: 락 획득 여부

[ 락 획득 시도 루프 시작 ]

Long ttl = this.tryAcquire(leaseTime, unit, threadId);
if (ttl == null) return true;

 
내부적으로 tryLockInnerAsync()를 통해 Lua 스크립트로 Redis에 락을 시도한다.
 

[ TTL 내에서 재시도 루프 (스핀락) ]

LockOptions.BackOffPolicy backOffPolicy = this.backOff.create();

do {
    current = System.currentTimeMillis();
    Thread.sleep(backOffPolicy.getNextSleepPeriod()); // 백오프 시간만큼 대기
    ttl = this.tryAcquire(leaseTime, unit, threadId);
    if (ttl == null) return true;
    time -= System.currentTimeMillis() - current;
} while(time > 0L);

• Pub/Sub 없이 while 루프로 계속 Redis에 락 요청을 보냅니다.
• 중간에 Thread.sleep()을 넣어 busy-wait 방지 (백오프 정책)
• TTL이 계속 반환되면 계속 재시도
• 타임아웃 초과 시 false 반환

---

정리하자면,

1. Redis에 락을 Lua 스크립트로 획득 시도 (tryAcquire)
2. 실패 시 → 백오프 정책에 따라 sleep 후 재시도 (spin lock)
3. waitTime이 있다면 남은 시간 계산, 0이면 실패 종료
4. 락을 획득하면 성공, leaseTime 없으면 watchdog 연장 등록

 
RedissonSpinLock은 Pub/Sub 기반의 블로킹 대기가 아닌, 재시도 루프 기반 락이다.
lock을 빠르게 잡거나 경쟁이 적은 환경에 적합하지만, 경쟁이 심하면 성능 저하 우려가 있다.

---

🪄정리

테이블 단위의 락보다 Redis를 활용한 락이 비즈니스 로직 수준에서 훨씬 유연하게 사용될 수 있으며, 다양한 자원에 적용 가능하다는 장점이 있다. 특히 Redisson을 통해 세마포어 Pub/Sub 기반의 락과 Spin 기반의 락이 각각 제공되고 있고, 사용 목적과 시스템 환경에 따라 적절한 방식을 선택해야 한다. 하지만 RedLock의 경우 내부에 합의 알고리즘이 없어 강한 일관성을 보장하지 못한다는 한계가 존재하므로 실무에서는 신중하게 적용해야 한다. 더 나아가 이러한 제약을 보완하고자 한다면 Zookeeper와 같은 합의 기반 시스템을 고려할 수 있다.

 

---

📙 출처

https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/

Distributed Locks with Redis

 
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

How to do distributed locking — Martin Kleppmann’s blog