태태개발일지 - DB Lock

DB LOCK

간단한 개념 정리를 위해서 간략하게 정리해본다.

 

문제상황

 

DB락을 사용할 때에는 동시에 접근할 가능성을 기준으로 낙관적락 을 쓸지, 비관적 락을 쓸지 결정하게된다.

 

낙관적락을 사용하는 경우

 

충돌이 발생할 가능성이 높을 때 + 만약 lock을 획득하지 못했을 때 취소해도 괜찮은 건지?를 따져보면 된다.

ex) 좌석 예약 (1,2,3,4,5)

 

1. 만약 10명이 2번좌석을 예약하기 API를 요청했을 때 그들중 한명이 좌석예약을 성공했다면, 그 다음사람들은 다시 다른 좌석을 예약야        한다. 즉) API 요청을 취소해버리면된다.

 

2. 좌석은 (1,3,4,5)로 보여주고 다시 시도할 사람은 다시 요청을 보내면된다.

 

비관적락을 사용하는 경우  

 

다음 요청도 실패로 하지않고 처리가 필요할 때 + 충돌이 다수 발생이 예상될때 -> 비관적 락 -> 공유락 , 배타락

 

ex) 선착순 쿠폰

 

1. 선착순대로 쿠폰발급 API 가 있다. 100명이 동시에 진입을 하였고, 한명이 Lock을 획득하여 쿠폰을 발급했다. 하지만 이후 99명의 요청을 취소해버린다면 선착순은 의미가 없어진다. 즉 실패요청을 하지않고 다음 요청이 필요하다. 

 

 

 

DB LOCK VS 분산 LOCK

 

DB 락을 사용하게 되면, 서버의 DBCP를 사용하게 되고 connection pool을 차지하게 된다. 하지만 수량의 한계가 1000명이라고 가정하면, 다른 사람들은 DB에 접근할 수 없게 된다.

 

*이런 상황에서 RDBMS에 대한 부하를 Reids같은  RDBMS가 아닌 곳에 분산시켜서 LOCK을 사용하면, 해결이 된다.*