https://velog.io/@wngus4278/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EB%9D%BDLock%EA%B3%BC-%EB%8F%99%EC%8B%9C%EC%84%B1
해당 글에서 비관적락과 낙관적락에 대해서 설명한 적이 있으나, 비관적락에 있는 공유락과 베타적락에 대해서 적을 예정이며, 또한 데드락에 대해서 작성할 예정이다.
✅ Lock?
- 동시성을 제어하는 기능
- 여러 커넥션에서 동시에 공유자원을 접근할때 순서대로 하나의 커넥션만 변경할 수 있게 해주는 기능
📌 Lock의 종류
- 낙관적 락 : 자원에 락을 걸어서 선점이 아닌, 동시성 문제가 발생하면 그때 가서 처리하자.
- 비관적 락 : 자원 요청에 따른 동시성 문제가 발생할 것이라고 예상하고 바로 락을 걸어버림.
ㄴ 공유 락(S-Lock)
ㄴ 베타 락(X-Lock)
✔️ 공유락
공유락은 데이터를 변경하지 않는 읽기 작업을 위해 잠그는 것이다.
세션 A가 특정 데이터를 읽기 위해 공유 Lock을 획득하고, 다른 세션B도 같은 데이터를 공유 Lock을 걸고 읽을 수 있지만, 어떤 세션도 해당 데이터를 베타 락을 걸고 수정할 수 없다.
=> 내가 데이터를 읽는 동안 읽기는 가능, BUT 변경하려고 선점하지말라
✔️ 베타락
베타락은 데이터를 변경하는 작업을 위해 잠그는 것이다.
세션 A가 특정 데이터를 쓰기 위해 베타 Lock을 획득했고, 어떤 세션도 해당 데이터를 읽기 위해 공유락을 걸고 있는 것은 불가능하며, 쓰기 위해 베타락을 걸고 쓰는 것이 불가능하다.
=> 내가 데이터 쓰는 동안 데이터를 읽거나 변경x
📌 데드락
데드락은 두 트랜잭션 모두가 블로킹(Lock간의 경합이 발생해 특정 트랜잭션이 작업을 진행못하고 대기하는 상태)상태에 진입하여 서로의 블로킹을 해결할 수 없는 상태임.
예를 들면, 트랜잭션 A,B가 있을 경우, A가 B트랜잭션에 대해 블로킹 상태로 진입했을 경우, B트랜잭션이 커밋or롤백이 이루어져야 A가 블로킹 상태가 풀리게된다.
하지만 트랜잭션 B또한 A에 대해서 블로킹 상태가 되었다면, B트랜잭션 또한 A트랜잭션이 커밋or롤백이 이뤄져야 블로킹 상태가 풀리게 된다. 하지만 둘다 상대 트랜잭션의 종료만을 기다리고 있으니,영원히 벗어날 수 없는 상태에 빠진다. 이를 데드락이라 한다.
하지만 대부분 사용하는 mysql은 데드락이 발생한다면 하나의 트랜잭션을 롤백시켜 데드락에서 벗어나게끔 한다.
https://ksh-coding.tistory.com/121
위에 있는 베타적락과 공유락은 DB자체에 행에 락을 거는 행위이다.
✔️ DB락의 문제점
- DB는 단일 자원이기 때문에 수평 확장이 쉽지 않음.
- 많은 트래픽이 몰릴 시 전체 시스템에 병목현상을 가져다줌. 특히 MSA처럼 여러 서비스가 동시에 하나의 DB에 접근하는 경우 DB 락 기반의 동시성 제어는 한계가 있음.
✔️ 그럼에도 DB 락이 유용한 경우
- 단일 DB에서 관리되는 소규모 시스템
- 예: 초기 스타트업이나 소규모 애플리케이션
- 트랜잭션 수가 적고 락 경합이 낮은 경우
- 락 충돌 가능성이 낮다면 DB 락이 오히려 간단하게 문제를 해결해 줄 수 있음
✔️ 왜 대규모 시스템에서는 DB 락이 별로일까?
- 트랜잭션 경합으로 인한 성능 저하
- DB 락은 트랜잭션 단위로 락을 설정하고 해제하기 때문에, 동시에 많은 트랜잭션이 발생하면 락 해제 대기 시간이 증가
- 특히 베타적 락(Exclusive Lock)은 다른 트랜잭션의 접근을 완전히 차단하기 때문에 병목 현상이 심각해질 수 있음
- DB 확장성에 제약
- DB는 단일 자원이라서 수평적 확장이 어려움.
- 트래픽이 늘어날수록 락 관리로 인한 부하가 급증하고, DB 락으로 처리할 수 있는 한계를 초과할 가능성이 있음.
이를 해결하기 위해서, 소프트웨어 락이 있다. 즉, 데이터베이스에 락을 거는 행위가 아닌, Redis나 zookeeper와 같은 외부 시스템을 사용하여 락을 관리한다.
DB에 직접 락을 설정하는 대신 어플리케이션 레벨에서 동시성을 관리하므로 성능이 개선될 수 있다.
