미로

주문을 받아와 처리를 하다보면  재고 처리를 위해 동시성 제어가 필요하다.

아래는 여러가지 방법을 간략하게 정리해보고  내가 선택한 방식 이유 와 장점을 정리했다.

1. Redis 큐를 이용한 직렬화 방식

Redis 리스트 자료구조를 활용해 큐를 만들어 처리 

큐의 FIFO 를 이용해  LEFT PUSH   이후  RIGHT POP을 통하여 메시지를 하나씩 꺼내 처리 

장점  -  비즈니스 무결성 보장, 고속 Redis 기반 처리로 성능 우수, DLQ 이용 실패한 큐의 재전송 용이

단점- Redis 장애 시 전체 시스템 영향 가능성, Redis TTL 설정 누락 시 큐가 무한히 쌓일 의험, 운영 중 큐/워크 스케쥴러 튜닝 필요

2.Synchronized, ReentrantLock (단일 인스턴스 JVM 내 락)

JAVA 자체  락을 통해 Critical Section을 직렬화

단일 서버 환경에 적합, Spring boot 단독 서버에서 간단하게 사용가능

장점 - 구현이 단순하고 추가 인프라 필요 X, JVM 내에서 완벽하게 락을 보장

단점 - 서버 인스턴스가 늘어나면 무용지물 (인스턴스별 메모리 영역 분리),  클러스터 환경에서는 동작 불가

현재 구조에 맞지 않음(멀티 서버 구조) 

3. 데이터베이스 기반의 락

비관적 락(Pessimistic Lock)

데이터를 SELECT FOR UPDATE 형태로 가져와 락을 건 채 트랜잭션을 유지

동시에 접근하는 모든 트랜잭션은 대기하게됨

//ex
@Lock(LockModeType.PESSIMISTIC_WRITE)
Order findByOrderNo(String orderNo);

장점 - 경쟁이 매우 치열하거나 순서 보장이 중요한 데이터에 적합, DB 레벨에서 무조건 직렬화 보장

단점 - 트랜잭션 지연 발생, 데드락 발생 위험

낙관적 락(Optimistic Lock)

레코드를 가져올 땐 락 없이 처리

저장 시점에 version필드 등을 비교해 충돌 여부 판단

//ex

@Version
private Long version;


order.setQty(10);
orderRepository.save(order); // version mismatch 시 예외 발생

장점 - 충돌이 적은 환경에서 효율적 (대부분의 웹 시스템에 적합), 락을 잡지 않으므로 성능 유리

단점 - 충돌 발생 시 재시도 로직 필요, 실시간성이 요구되는 시스템에는 부적합

4. Redis 분산 락 (Redisson / Lettuce)

Redis SETNX 또는 Lua 스크립트를 활용해 락 키를 생성하고 만료 시간을 설정

멀티 인스턴스 환경에서 유일한 자원 접근 보장

//ex

RLock lock = redissonClient.getLock("lock:account:" + accountId);
if (lock.tryLock(5, 10, TimeUnit.SECONDS)) {
    try {
        // 주문 처리
    } finally {
        lock.unlock();
    }
}

장점 - 클러스트 환경에서의 락 보장,TTL 및 자동 만료 설정 가능

단점 - 락 획득 실패 시 로직 설계가 필요, Redis 장애 시 전체 처리 지연 가능

*락 키는 "lock:business-key" 형태로 설계하여 중복 방지

5. Kafka 파티셔닝 기반 직렬화

Kafka의 파티셔닝 기능을 활용해 동일한 accountId 가 항상 같은 Partition으로 전송되도록 설정

Consumer는 파티션 단위로 순차 소비

//ex
//consumer는 파티션 내부에서는 메시지 순서보장
ProducerRecord<String, String> record = new ProducerRecord<>("topic", accountId, payload);

장점 - 높은 확장성과 처리량( 수평 확장에 최적화), 분산환경에서도 순차 보장 가능

단점 - Kafka 운영 복잡도 증가(broker, topic, consumer group 관리), 장애 복구나 DLQ 재처리에 별도 설계 필요

* 이벤트 기반 마이크로서비스, 대용량 메시징 시스템

방법 환경 순서 보장 분산 처리 성능 복잡도

현재 작업중인 서버를 고려해 1번 Redis 큐를 활용한 방법을 선택했따.

• 외부 API 호출 기반의 처리 구조
• 계정 단위 직렬화 처리 필요
• 장애 발생 시 유연한 재처리 체계 필요
• 복잡하지 않으면서도 확장 가능한 구조 지향

결과적으로 Redis 큐를 중심으로 구성한 주문 처리 워커 및 DLQ 재처리 시스템은 고립된 처리 단위를 보장하면서, 비즈니스의 신뢰성을 유지하고, 운영 편의성과 확장성까지 확보할 수 있는 적절한 선택이지 않나 싶다.