동시성 해결하기(feat. TMI 주의)

  • 동시성 해결하기에 앞서 트랜잭션의 특징을 간단히 살펴보자.

  • 자세한 내용은 다음 링크를 통해서 알수 있다 (데이터베이스 격리수준)

트랜잭션 특성(ACID)

  • 원자성(Atomicity) : 트랜잭션은 모두 실행되거나 아예 실행되어서는 안된다

  • 일관성(Consistency) : 데이터베이스 속성은 항상 일관되게 유지되어야 한다

  • 격리성/독립성(Isolation) : 각각의 트랜잭션은 서로 독립적으로 동작하고 영향을 주지 않아야 한다.

  • 지속성(Durability) : 트랜잭션이 완료된 이후에는 영구적으로 반영되어야 한다

트랜잭션 격리수준

  • 트랜잭션의 독립성을 보장할 수 있는 격리수준은 다양하다

  • 격리수준을 높일수록 동시성은 보장되지만 성능은 하락할 수 있다

  • 서비스 성격에 맞게 격리수준을 적절히 적용할 필요가 있다

  • 격리수준의 상세한 설명은 다음 링크를 통해서 알수 있다 (데이터베이스 격리수준)

  • 동시성을 해결하기 위해서는 수행되는 락을 확인하기 위한 방법을 살펴보자

테이블 락 조회 방법

테이블 락

  • 테이블에 LOCK을 걸어 테이블의 데이터의 접근을 제한할 수 있다

  • 테이블의 데이터 읽기/쓰기 제한(CRUD 쿼리 제한)

// format
LOCK TABLES {tableName} WRITE;

// example(TB_PRODUCT 테이블에 WRITE LOCK을 건다)
LOCK TABLERS TB_PRODUCT WRITE;

  • 테이블의 데이터 읽기 제한(CUD 쿼리 제한)

// format
LOCK TABLES {tableName} READ;

// example(TB_PRODUCT 테이블에 READ LOCK을 건다)
LOCK TABLERS TB_PRODUCT READ;

테이블 락 해제

  • 락이 걸린 테이블을 해제할 수 있다

  • UNLOCK 명령어를 사용하면 테이블 락을 해제할 수 있다.(단, LOCK을 수행한 콘솔 내에서만 가능하다)

UNLOCK TABLES;

락 테이블 조회

  • 락이 걸려 있는 테이블을 조회할 수 있다

SELECT * FROM performance_schema.metadata_locks;

  • 사전에 테이블에 READ LOCK을 수행하였다

LOCK TABLES TB_SETTLEMENT_DETAIL READ;

결과 화면

대기중인 락 조회

  • 현재 대기중인 락을 조회할 수 있다

SELECT * FROM performance_schema.data_locks;

  • 사전에 특정 데이터를 LOCK으로 홀드한다

SELECT COUNT(*) 
FROM TB_SETTLEMENT_DETAIL 
WHERE 4201 <= settlement_detail_id AND settlement_detail_id <= 4203 FOR UPDATE;

결과화면

💡 LOCK_MODE 데이터 확인

X : 넥스트 키 락

X,REC_NOT_GAP : 레코드 락

X,GAP : 갭 락

IX : 테이블 락(인텐트 락, X LOCK 생성시)

IS : 테이블 락(인텐트 락, S LOCK 생성시)

실행중인 트랜잭션 조회

  • 실행 되고 있는 트랜잭션을 확인할 수 있다

SELECT * FROM information_schema.INNODB_TRX;

  • 사전에 테이블을 LOCK 하였다

LOCK TABLES TB_SETTLEMENT_DETAIL READ;

결과화면

프로세스 조회

  • 실행중인 쿼리 목록을 보여준다

SHOW FULL PROCESSLIST;

  • 사전에 테이블을 LOCK 하고, INSERT 하는 쿼리를 수행하였다

LOCK TABLES TB_SETTLEMENT_DETAIL READ;
insert into TB_SETTLEMENT_DETAIL (settlement_id, settlement_detail_amount, receiver_id,
                                  settlement_detail_complete_yn, settlement_detail_complete_ymdt)
values (1, 1000, 1,false,now());

결과화면

락으로 인해 대기중인 쿼리 중지

  • 데드락 또는 테이블에 락이 발생할때 대기 중인 쿼리를 임의로 중지할 수 있다 (사전에 SHOW PROCESSLIST; 를 수행해서 ID를 확인해야 한다)

// format
KILL {PID};

// ID가 '10'인 쿼리 수행을 종료한다
KILL 10;

데이터베이스 락 범위

  • 데이터베이스에 직접 LOCK을 걸 수 있는 방법은 다양하다

  • 수행하는 LOCK에 따라서 적용되는 범위도 다양하다

table lock(테이블 락)

  • 테이블 단위로 LOCK을 생성할 수 있다

  • READ는 데이터를 읽을순 있지만, CUD는 할수 없다

  • WRITE는 데이터에 대한 CRUD 작업이 불가능하다

// format
LOCK TABLES {table-name} READ || WRITE

// example
LOCK TABLES TB_PRODUCT READ;
LOCK TABLES TB_PRODUCT WRITE;

row level lock(로우 레벨 락)

  • 테이블의 데이터 로우 단위로 LOCK을 생성할 수 있다

  • 로우 레벨 락은 상태값으로는 확인할 수 없다 (내부 엔진에서만 수행되어 LOCK이 걸릴 경우, 수정이 안되면 로우 레벨 락이 수행되었다고 가정한다)

  • 로우 레벨 LOCK은 S LOCK, X LOCK을 통해서 설정할 수 있다

// example
SELECT * FROM TB_PRODUCT WHERE product_id = 1 FOR SHARE // S LOCK
SELECT * FROM TB_PRODUCT WHERE product_id = 1 FOR UPDATE // X LOCK

record lock(레코드 락)

  • 인덱스가 존재할 경우, 데이터 테이블이 아닌 인덱스 테이블에 LOCK이 생성된다

// example
SELECT * FROM TB_PRODUCT WHERE product_id = 1 FOR SHARE // S LOCK
SELECT * FROM TB_PRODUCT WHERE product_id = 1 FOR UPDATE // X LOCK

결과화면

gap lock(갭 락)

  • 갭락의 범위는 조건에 해당하는 범위 내에서 비어있는 영역을 LOCK 할 경우에 생성된다

SELECT COUNT(*)
FROM TB_SETTLEMENT_DETAIL 
WHERE settlement_detail_id BETWEEN 4194 AND 4200 FOR UPDATE;

  • 예시로 수행한 쿼리에서 4196, 4195, 4196, 4197, 4199 데이터가 존재한다

결과화면

next key lock(넥스트 키 락)

  • 레코드 락과 갭 락을 조합한 것이다

  • 범위에 존재하는 데이터는 레코드 락이 발생하고 존재하지 않는 범위에는 갭락이 생성된다

  • mysql innoDB에서는 넥스트 키 락으로 인해 격리 수준이 repeatable read 단계에서도 phantom read가 발생하지 않는다.

  • 왜냐하면 넥스트 키 락으로 인해 트랜잭션 범위 이외에도 인덱스 앞뒤로 락이 생성되어 데이터 생성/삭제를 제한할 수 있다

SELECT *
FROM TB_SETTLEMENT_DETAIL
WHERE settlement_detail_id BETWEEN 4547 AND 4549 FOR UPDATE;

결과화면

넥스트 키 락은 보통 어디에서 사용하지???

  • MYSQL에서 repeatable read 단계에서도 Phantom read가 발생하지 않는 이유가 넥스트 키 락 덕분이다

Phantom read란??

한 트랜잭션 내에서 데이터 조회시, 추가/삭제하는 데이터에 대해서는 일관성을 보장하지 않는다 일반적인 데이터베이스 격리수준은 repeatable read 단계에서도 발생한다. 그리고 이를 해결하기 위해서는 격리수준을 serializable 단계로 전환해야 해결할 수 있다

  • 우선 mysql의 Phantom read 이슈를 알아보기 전에 mysql의 매커니즘을 살펴볼 필요가 있다

  • 대부분의 데이터베이스는 동시성 문제를 해결하기 위해 MVCC 매커니즘을 활용한다

MVCC(Multi-Version Concurrenty)

  • MVCC는 다중 버전 동시성 제어를 뜻한다

  • MVCC의 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는데 있다

  • Multi version 이라는 것은 스냅샷을 통해 하나의 레코드에 대해 여러 버전이 관리된다는 것을 의미한다

  • MVCC의 가장 큰 장점은 LOCK을 사용하지 않기 때문에 동시성 제어에 성능을 보장할 수 있다

  • 스냅샷은 보통은 undo 로그 파일을 사용한다

undo 로그는 크게 두 가지 용도로 사용된다

  • 트랜잭션의 롤백 대비

  • 트랜잭션의 격리 수준을 유지하면서 높은 동시성을 제공

그럼 MVCC로 Phantom read를 해결할 수 있는가?

  • 아니다. MVCC 만으로는 Phantom read를 해결 할 수 없다

  • 그러나 mysql의 innoDB는 트랜잭션 내에서 LOCK을 생성하였다면, next-key lock을 통해서 조회 범위 다음 영역까지 GAP LOCK을 생성하여 생성/삭제 되는 커밋을 제한 할 수 있다

그럼 우리는 격리수준만 설정하면 동시성 제어를 고려하지 않아도 될까?

  • 아니다. 이전까지 살펴본건 데이터베이스 내에서 격리수준에 따라 독립성을 보장하는 과정을 살펴봤다

  • 서비스를 구현하다보면 서비스 가용성을 확보하면서 동시성 제어를 직접 구현해야하는 경우가 있다 (ex. 재고차감, 선착순 모집, 파격세일 주문)

직접 제어할 수 있는 방법은 크게 두 가지로 나뉠수 있다

  • 하나는 쿼리를 작성하여 직접 LOCK을 제어할 수 있다

  • 다른 하나는 애플리케이션 내에서 동시성을 제어할 수 있다

쿼리 레벨에서 동시성 제어

공유 락(shared lock)

  • 서로 다른 트랜잭션에 대해서 동일한 자원에 대해 READ는 허용하지만, WRITE는 제한한다

  • 보통 S LOCK으로 표현한다

그럼 쿼리로는 어떻게 작성할 수 있을까?

SELECT * FROM TB_INVENTORY WHERE inventory_id = 101 LOCK IN SHARE MODE; // mysql 5.7 이하
SELECT * FROM TB_INVENTORY WHERE inventory_id = 101 FOR SHARE; // mysql 8.0 이상

베타 락(exclusive lock)

  • 서로 다른 트랜잭션에 대해서 선점한 트랜잭션이 COMMIT할때까지 나머지 트랜잭션은 BLOCK 된다

  • 보통 X LOCK으로 표현한다

그럼 쿼리로는 어떻게 작성할 수 있을까?

SELECT * FROM TB_INVENTORY WHERE inventory_id = 101 FOR UPDATE // mysql 5.7 , 8.0 모두 동일

인텐트 락(intent lock)

  • 인텐트 락은 직접 쿼리로 작성 하기보다는 공유 락이나 베타 락을 수행하면 테이블에 추가적으로 생성되는 락이라고 보면 된다

  • 생성되는 락에 따라서 인텐트 락에 대한 값은 다르지만 기능은 동일하다

  • 트랜잭션 내에서 테이블의 스키마를 수정하지 못하게 하여 일관성을 유지하기 위함이다

  • is : S LOCK 생성시, 테이블에 생성되는 락

  • ix : X LOCK 생성시, 테이블에 생성되는 락

애플리케이션 레벨에서 동시성 제어

  • 프레임워크를 사용하고 있다면 라이브러리 내에서 동시성을 제어해주는 다양한 방법이 있다

낙관적 락

ORM - JPA

  • ORM에서 JPA를 사용하고 있다면, LockMode.OPTIMISTIC으로 처리할 수 있다

  • @Entity 객체에는 낙관적 락에 필요한 @Version 필드가 필요하다

OptimisticLockException은 어떻게 발생할까?

EntityManager가 update할 경우, row count가 0일 경우 버전 정보가 잘못되었다고 판단하여 exception이 발생한다

  • 디버깅을 해보면 row count가 기대한 1이 아니라는 문구를 확인할 수 있다

  • JPA에서는 OptimisticLockException 리턴하게 되고

  • hibernate에서 StaleStateException을 리턴한다

  • spring은 ObjectOptimisticLockingFailureException 을 리턴한다

// entity 클래스
@Entity
class Student {

	...
	@Version
	private long version;
}

// 조회시 LockModeType을 OPTIMISTIC 으로 설정
entityManager.find(Student.class, studentId, LockModeType.OPTIMISTIC);

ORM - MYBATIS

  • ORM을 mybatis로 사용한다면 직접 구현해야 한다

  • version 필드를 추가하여 데이터를 조회하고 수정시 version 정보가 동일한지 확인한다

  • 업데이트 이후에 반영된 column 갯수가 0개인지 확인하고 서비스에 필요한 예외처리를 구현한다

    while (true) {
	// 상품 데이터를 조회한다
	Product product = productRepository.findByProductId(productId);

	// 상품 데이터가 업데이트 되었는지 확인한다
	int count = productRepository.update(UpdateProductParameter.builder()
		.productId(parameter.getProductId())
		.version(settlement.getVersion())
		.build());

	// 업데이트 되었다면 루프문을 나온다
	if(count > 0) {
		return;
	}

	// 루프문을 시도하는 횟수를 초과했다면 exception을 리턴한다
	if (retryCount > MAX_RETRY_COUNT) {
		throw new RuntimeException("상품 수정에 실패하였습니다.");
	}

	// 재시도 횟수를 증가시킨다
	retryCount++;
}

낙관적 락으로 동시성 제어를 모두 해결할 수 있을까?

  • 그렇지 않다. 낙관적 락으로는 한계가 있다

  • 우선 낙관적 락은 충돌시 예외 처리를 직접 구현해주어야 한다

  • 만약 충돌시 재시도가 필요하다면, 재시도 횟수에 따라 데이터베이스 I/O가 발생하여 부하가 증가한다

  • 그리고 재시도하는 횟수에 따라 애플리케이션의 가용성도 저하된다

  • 만약 동시성 제어 로직 내에서 FK가 존재하는 테이블을 수정하는 경우에는 데드락이 발생시킬 수 있다 (참고 : 참조키 제약 조건 낙관적락 이슈)

  • 이런 문제를 보완할 수 있는 방법은 비관적 락을 사용하는 것이다

비관적 락

  • 비관적 락을 설정하면 다른 트랜잭션은 BLOCKING되어 커밋될 때까지 대기하게 된다

  • 비관적 락을 설정할 때는 TIMEOUT 설정을 꼭 해야 한다. 설정하지 않으면 데이터베이스에 따라서 설정된 lock timeout 시간 동안 대기하게 된다(단, JPA에서 지원해주는 기능이라 다른 ORM은 바로 exception이 발생할 수 있다. 그러니 명시적으로 TIMEOUT을 설정하는게 확실하다)

lock timeout 확인하기

기본 설정된 timeout 시간을 확인하려면 MYSQL에서는 innodb_lock_wait_timeout 값을 확인하면 된다

select @@innodb_lock_wait_timeout;

ORM - JPA

  • ORM이 JPA에서 LockMode.PESSIMSTIC으로 처리할 수 있다

    @Lock(LockModeType.PESSIMISTIC_WRITE)
@QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value ="5000")})
Stock findById(String id)

ORM - MYBATIS

  • MYBATIS를 사용하게 되면 SELECT FOR UPDATE 쿼리를 직접 호출하면 해결할 수 있다

  • timeout 설정은 수행 쿼리 단위로 독립적으로 설정할 수 있다

<select id="getSettlementById" parameterType="int" resultType="com.example.settlement.domain.settlement.model.Settlement" timeout="5000">
    /*SettlementMapper.getSettlementById*/
    SELECT
        settlement_id as settlementId,
        version as version,
        total_settlement_amount as totalSettlementAmount,
        requester_id as requesterId,
        settlement_complete_yn as settlementCompleteYn,
        settlement_complete_ymdt as settlementCompleteYmdt,
        requested_ymdt as requestedYmdt
    FROM TB_SETTLEMENT
    WHERE settlement_id = #{settlementId}
    FOR UPDATE
</select>

그럼 비관적 락을 사용하면 만능일까?

  • 그렇지 않다. 동시성은 확실히 보장할 순 있지만 요청이 BLOCKING 되어 서비스 성능이 저하될수 있고, 남용하게 되면 다양한 테이블에 BLOCKING 되어 데드락이 발생할 수 있다

  • 다음과 같은 상황이 있을 수 있다

    • 트랜잭션 A가 테이블1의 1번 데이터에 lock을 획득

    • 트랜잭션 B가 테이블2의 1번 데이터에 lock을 획득

    • 트랜잭션 A가 테이블2의 1번 데이터에 lock 획득 시도(실패 - 대기)

    • 트랜잭션 B가 테이블1의 1번 데이터에 lock 획득 시도(실패 - 대기)

  • 그래서 비관적 락은 주의해서 사용해야 한다

  • 이를 해결하려면 네임드 락이나 분산락을 사용해야 한다

분산락

  • 분산락이란 경쟁 상황(Race Condition)이 발생할때, 하나의 공유자원을 충돌이 발생하지 않도록 보유하는 기법이다

  • 분산락은 낙관적 락이나 비관적 락으로 발생하는 문제점을 보완하고, 애플리케이션 규모가 점차 커지면서 다중 서버/데이터베이스를 운영하는 과정에서 동시성을 보장하려고 할때 사용할 수 있다

  • 분산락을 구현하는 방법은 다양하다.

  • MySQL에서 네임드 락을 사용해 구현할 수 있고, 레디스 캐시를 사용해 구현할 수 있다

  • 그럼 다음 내용은 분산락을 구현하는 방법에 대해서 살펴보자

Named lock(네임드 락)

  • 네임드 락은 데이터베이스에 LOCK을 획득하여 다른 트랜잭션은 LOCK이 해제된 이후에 획득할 수 있다

  • 주의할 점은 락을 획득하기 위해 Connection을 유지해야 하므로 애플리케이션에서 데이터베이스에 Connection Pool이 부족할 수 있다

  • 그렇기 때문에 네임드 락은 실무에서는 별도 데이터베이스를 구축해서 사용해야 서비스 운영이 필요하다

  • 그리고 커넥션을 생성한 세션에서만 Connection을 닫을수 있으므로 주의해서 사용해야 한다

락 획득하기

  • 락을 획득하기 위해서는 획득 하려는 락의 이름과 획득을 시도하려는 TIMEOUT 시간을 정의하면 획득할 수 있다

@Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
void getLock(String key);

락 해제하기

  • 획득한 락을 해제하기 위한 방법으로 락의 이름으로 해제할 수 있다

@Query(value = "select release_lock(:key)", nativeQuery = true)
void releaseLock(@Param("key") String key);

lettuce

  • 네임드 락은 실무에서 사용하기엔 Connection Pool 이슈도 있고, 세션 관리도 해주어야 하므로 여러가지 신경써야 하는 부분이 있다

  • 레디스를 사용해서 분산락을 구현하면 어느정도 이러한 문제를 해소할 수 있다. Lettuce를 사용하고 있다면 SETNX를 활용해서 반복적으로 락 획득을 시도하여 락을 점유할 수 있다. 이는 스핀락(spinlock) 개념이라 할 수 있다

락 획득하기

  • 락을 획득하기 위해 레디스에 Key와 TTL 값을 설정한다

public Boolean lock(Long key) {
    return redisTemplate
            .opsForValue()
            .setIfAbsent(generateKey(key), "lock", Duration.ofMillis(3_000));
}

락 해제하기

  • 락을 해제하기 위해 해당 Key값을 기준으로 해제한다

public Boolean unlock(Long key) {
    return redisTemplate.delete(generateKey(key));
}

락 획득시도하기

  • 락 획득하기 위해 반복문을 사용하여 주기적으로 시도해본다

  • 레디스는 싱글 쓰레드로 동작하기 때문에 너무 반복적으로 시도하면 레디스에 부하만 가중되니 어느정도 interval을 두는게 좋다

  • 또한, 재시도 횟수를 설정하여 무한정 재시도하지 않도록 제한을 걸어두어야 한다

  • interval이나 재시도 횟수 제한으로 레디스에 발생하는 부하를 줄일 수 있지만 이는 실무에 여러가지 상황을 고려해서 설정해야 한다

public void decrease(Long id, Long quantity) throws InterruptedException {
    while (true) {
        try {
            optimisticLockStockService.decrease(id, quantity);

            break;
        } catch (Exception e) {
            System.out.println(e);
            Thread.sleep(50); // interval을 둔다
        }
    }
}

Redisson

  • redisson은 실제로는 자바 언어에 국한된 레디스 분산락 클라이언트이다

  • 레디스 분산락 라이브러리는 클라이언트 언어에 따라 다양한 라이브러리를 제공한다

  • 자세한 내용은 다음의 글을 참조하면 도움이 될 것이다 (redisson trylock 내부로직 살펴보기)

  • redisson을 사용하려면 우선 라이브러리를 import 해야 한다

// build.gradle
implementation 'org.redisson:redisson-spring-boot-starter:3.17.4'

획득할 락 정의하기

  • 이름으로 락을 획득 할 수 있다

RLock lock = redissonClient.getLock(key);

락 획득하기

  • 락 획득을 시도할 시간, 획득시 점유할 시간과 시간에 대한 단위를 명시하면 된다

boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);

락 해제하기

  • 점유한 락을 지정한 점유시간 보다 더 일찍 완료 되었다면, 임의로 해제시켜야 한다

  • 단, 여기서 주의할 점은 점유한 락을 해제할 경우에는 lock이 현재 점유된 상태인지 그리고 해제 하려는 세션에서 생성한 lock인지 꼭 확인하고 해제해야 한다

  • 보통 점유한 lock을 명시적으로 해제시키기 위해 finally 블럭 내에서 수행하는데, exception이 발생하는 경우에도 lock이 해제될수도 있으니 위와 같은 검증 이후에 lock을 해제하는게 중요하다!!

if (lock.isLocked() && lock.isHeldByCurrentThread()) {
	lock.unlock();
}

전체 소스 코드

public void decrease(String key, Long quantity) {
	RLock lock = redissonClient.getLock(key);

	try {
		boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);

		if (!available) {
			System.out.println("lock 획득 실패하였습니다");
			return;
		}

		stockService.decrease(key, quantity);
	} catch (InterruptedException e) {
		throw new RuntimeException(e);
	} finally {
		if (lock.isLocked() && lock.isHeldByCurrentThread()) {
			lock.unlock();
		}
	}
}

정리를 해보자면!!

  • 애플리케이션이 규모가 적은 단일 애플리케이션/데이터베이스를 사용하는 상황에서 동시성을 보장해야 한다면 데이터베이스만으로 낙관적 락이나 비관적 락으로 해결할 것이다

만약 낙관적 락을 사용한다고 하면?

  • 공유 데이터에 대한 read 비율이 높고, 충돌 빈도가 적다면 낙관적 락을 사용할 것이다

  • 또는, 충돌에 대해서 재시도가 없이 실패로 처리한다면 낙관적 락이 서비스 가용성 측면에서도 유일할 것이다

  • 그러나 처음엔 충돌 빈도가 적었지만, 서비스가 점차 확장되면서 충돌 빈도가 증가한다면 비관적 락으로 전환할 것이다

만약 비관적 락을 사용한다면?

  • 충돌 빈도가 높다면 비관적 락을 사용할 것이다

  • 또는 낙관적 락을 사용하다 데드락이 발생하는 케이스에 대해서도 비관적 락으로 해결할 것이다

그럼 분산락은 언제 사용하면 좋을까?

  • 비관적 락을 사용하다 데드락이 발생하거나 애플리케이션의 규모가 커지면서 트래픽이 증가하여 충돌에 빈도수가 증가한다면 분산락으로 전환할 것이다

그렇다면 분산락은 데이터베이스로 구현할지 레디스 캐시로 구현할지?

  • 실무에선 네임드락을 사용하는건 어렵다고 생각한다. 커넥션 풀 이슈도 있어서 별도 데이터베이스를 구축해야 하고, 세션에 따라서 락을 조정해야 하기 때문이다

  • 그리고 무엇보다 데이터베이스 보다는 레디스가 I/O 성능상 가볍기 때문에 레디스로 분산락을 구현하여 사용할 것이다

레디스를 사용한다면 lettuce을 사용할까? redisson을 사용할것인가?

  • lettuce을 사용한다면 스핀 락으로 인해 레디스에 부하가 많이 발생해서 다소 제한적인 범위에서 사용할 것이다. 또는 충돌에 대한 재시도 없이 실패로 간주한다면 lettuce만으로 충분할것이다

  • 그렇지만 충돌이 많이 발생하고 어느정도 재시도가 필요하다면 redisson을 사용할 것이다

참고

PreviousRestTemplate 사용시 주의사항Nextredisson trylock 내부로직 살펴보기

Last updated