💡 Redisson을 제외하고 동시성 제어를 하는 방법 중 Lock(락)에 대해 알아보자.
동시성을 제어할 때 동시에 여러명이서 요청을 보낼 시 상당히 많은 양의 트랜잭션이 수행되게 된다.
이때 동시에 수행하면서 트랜잭션을 공유하다보면 시작점이 겹치게 되는 경우가 생기고 이로 인해 데이터의 일관성이 떨어질 수 있다.
갱신 손실 문제
ex) A가 좋아요를 누를때 기존 좋아요 개수: 1, B가 좋아요를 누를 때도 좋아요 개수가 1인 경우 A, B가 좋아요를 누르면 3이 되어야하나 서로 1일 때 트랜잭션을 시작했기 때문에 3이 나오지 않는다.
즉, 트랜잭션이 여러개 실행될 때 트랜잭션한 결과가 사라지게 된다.
갱신 손실 문제를 해결하기 위한 락
대표적인 예시로 비관적 락과 낙관적 락이 존재한다.
비관적 락 (Pessimistic Lock)
비관적 락은 데이터에 대한 접근을 엄격히 제어하여 다른 트랜잭션이 동시에 같은 데이터에 접근하지 못하도록 한다. 비관적 락은 데이터의 충돌이 자주 발생할 것으로 예상되는 상황에서 사용된다.
특징
- 락 획득: 데이터에 접근하기 전에 먼저 락을 획득한다.
- 동시성 제어: 다른 트랜잭션이 락을 획득할 때까지 대기해야 한다.
- 안전성: 데이터의 일관성을 확실히 보장한다.
- 성능: 락을 획득하고 해제하는 과정에서 성능 저하가 발생할 수 있다.
낙관적 락 (Optimistic Lock)
낙관적 락은 데이터 충돌이 드물게 발생할 것으로 가정하고, 데이터에 대한 락을 걸지 않는다.
대신, 트랜잭션이 커밋되기 전에 데이터의 변경 여부를 확인하여 충돌이 발생하면 트랜잭션을 재시도한다.
특징
- 락 미사용: 데이터에 대한 락을 사용하지 않는다.
- 충돌 검사: 트랜잭션이 끝날 때 데이터의 버전을 확인한다.
JPA에서@Version어노테이션을 사용하여 버전을 확인한다. - 성능: 비관적 락보다 성능이 좋다.
- 안전성: 충돌이 발생하면 트랜잭션을 재시도한다.
결론
- 비관적 락: 데이터 충돌이 빈번하게 발생할 경우 사용하며, 데이터의 일관성을 확실히 보장하지만 성능 저하가 발생할 수 있다.
- 낙관적 락: 데이터 충돌이 드물게 발생할 경우 사용하며, 성능이 우수하지만 충돌이 발생할 때는 트랜잭션을 재시도해야 한다.
고로 나와 같이 좋아요 기능과 같은 기능을 구현할 때는 빈번하게 사용자가 클릭을 할 수 있다.
예를 들어 무신사 상품 좋아요를 누르는 것과 같이 동시에 여러 명이 누를 가능성이 있는 이러한 경우는 비관적 락을 처리하는 것이 좋아보인다.
