낙관적 락/비관적 락/분산락 차이 - 재고 감소 동시성 문제를 5가지 방식 코드로 비교

배경

@Test
@DisplayName("동시에 100개의 재고 감소 요청이 와도 재고는 정확히 0이 된다")
void concurrent_decrease() throws InterruptedException {
    int threadCount = 100;
    ExecutorService executorService = Executors.newFixedThreadPool(32);
    CountDownLatch latch = new CountDownLatch(threadCount);

    for (int i = 0; i < threadCount; i++) {
        executorService.submit(() -> {
            try {
                stockService.decrease(stockId, 1L);
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();
    executorService.shutdown();

    Stock stock = stockRepository.findById(stockId).orElseThrow();
    assertThat(stock.getQuantity()).isZero();
}

1. 비관적 락 (Pessimistic Lock) — SELECT ... FOR UPDATE

public interface PessimisticStockRepository extends JpaRepository<Stock, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    Stock findWithPessimisticLockById(Long id);
}

SELECT *
FROM stock
WHERE id = ?
FOR UPDATE;

@Transactional
public void decrease(Long id, Long quantity) {
    Stock stock = stockRepository.findWithPessimisticLockById(id);
    stock.decrease(quantity);
}

• 언제 쓰나: 동일한 행에 대한 경합이 자주 발생하고, 충돌 가능성이 높은 경우에 적합하다. 낙관적 락은 충돌할 때마다 트랜잭션을 다시 실행해야 한다. 충돌이 드물면 효율적이지만, 같은 재고 행에 요청이 집중되면 재시도가 반복될 수 있다. 이런 상황에서는 처음부터 비관적 락으로 요청을 순차 처리하는 편이 더 안정적이다.

2. 낙관적 락 (Optimistic Lock) — @Version

@Entity
public class Stock {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long quantity;

    @Version
    private Long version;
}

UPDATE optimistic_stock
SET quantity = ?, version = version + 1
WHERE id = ? AND version = ?;

@Component
public class OptimisticLockStockFacade {

    private static final int MAX_RETRY = 100;

    public void decrease(Long id, Long quantity) throws InterruptedException {
        for (int retry = 0; retry < MAX_RETRY; retry++) {
            try {
                stockService.decrease(id, quantity);
                return;
            } catch (ObjectOptimisticLockingFailureException e) {
                Thread.sleep(50);
            }
        }
        throw new IllegalStateException("재시도 횟수 초과: 낙관적 락 충돌이 계속 발생했습니다.");
    }
}

• 언제 쓰나: 경합이 낮을 때 - 회원 정보 수정, 게시글 수정처럼 같은 행을 동시에 고칠 확률이 낮은 경우. 선착순 이벤트처럼 한 행에 요청이 몰리는 상황에는 부적합하다.

DB 락도 여러 서버에서 동작한다

3. Lettuce SET NX 직접 구현 — 스핀락

public boolean lock(Long id, String token) {
    return Boolean.TRUE.equals(
            redisTemplate.opsForValue()
                    .setIfAbsent(key(id), token, Duration.ofMillis(3_000)));
}

• NX: 키가 존재하지 않을 때만 저장

• PX 3000: 키 만료 시간을 3,000ms(3초 TTL)로 설정

• token: 락을 획득한 소유자를 식별하는 값, TTL 만료 후 다른 스레드가 잡은 락을 실수로 지우지 않기 위해 저장

private static final DefaultRedisScript<Long> UNLOCK_SCRIPT = new DefaultRedisScript<>(
        """
        if redis.call('get', KEYS[1]) == ARGV[1] then
            return redis.call('del', KEYS[1])
        else
            return 0
        end
        """, Long.class);

public void decrease(Long id, Long quantity) throws InterruptedException {
    String token = UUID.randomUUID().toString();

    while (!lockRepository.lock(id, token)) {
        Thread.sleep(100);
    }
    try {
        stockService.decrease(id, quantity);
    } finally {
        lockRepository.unlock(id, token);
    }
}

• 언제 쓰나: 분산락의 내부 동작 원리를 학습할 때, 또는 분산락을 단순하게 직접 구현해도 되는 환경(경합이 적고 요구사항이 단순한 경우). 실무에서는 단순한 SET NX 한 줄보다 예외 상황이 훨씬 많기 때문에, 직접 구현해야 할 특별한 이유가 없다면 Redisson 같은 검증된 분산락 라이브러리를 사용하는 경우가 안전하다.

4. Redisson — pub/sub 대기

public void decrease(Long id, Long quantity) throws InterruptedException {
    RLock lock = redissonClient.getLock("stock-lock:" + id);

    boolean acquired = lock.tryLock(10, 3, TimeUnit.SECONDS);
    if (!acquired) {
        throw new IllegalStateException("락 획득에 실패했습니다.");
    }
    try {
        stockService.decrease(id, quantity);
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

• waitTime: 락 획득을 최대 10초 동안 기다림. pub/sub 알림 기반이라 대기 중에 스핀하지 않는다.

• leaseTime: 락 획득 후 3초가 지나면 자동 해제. 죽은 서버가 락을 무한 점유하는 것을 막는다.

• 언제 쓰나: 다중 서버에서 특정 키에 경합이 심할 때(선착순 쿠폰, 타임세일 재고), 또는 락 점유 시간이 일정하지 않아 자동 TTL 연장이 필요할 때.

정리 — 한 표로

• 단일 DB + 경합 잦음 → 비관적 락. 줄 세우는 게 재시도보다 싸다.

• 경합 드묾 → 낙관적 락. 락 비용 없이 감지만

• 다중 서버 + DB 부하 분리 필요 → Redis 분산락. 경합이 심하면 pub/sub 대기를 지원하는 Redisson, 대기가 필요 없는 단순한 경우라면 SET NX 직접 구현