필자는 이번 프로젝트에서 이벤트 기능을 맡게되었다.
이벤트 기능의 주요 서비스는, 여러명의 사용자가 포인트를 지불하고 이벤트에 참여하면 이벤트에 누적 금액이 쌓이게되고, 목표 금액에 달성한 사용자만이 티켓을 얻게되는 이벤트이다.
때문에 이벤트 응모 요청은 동시에 여러명이 요청할 수 있는 API이다.
이런 사용자의 요청이 모두 다 정상적으로 반영되면 좋겠지만, 실제로는 동시에 여러명이 요청을 할 경우, 누적금액이 모두 정상적으로 반영이 될까? 결과부터 말해보자면 그렇지않다. 이런 동시성 문제를 해결하기 위해서는 Lock에 대한 기본적인 이해도가 필요하다. 이번 기회에 공부하며 알아보도록하자.
락은 트랜잭션 처리의 순차성을 보장하기 위한 방법이다. (트랜잭션이란 DB에서 나누어지지않는 가장 최소의 처리 단위이다.) 데이터의 일관성과 무결성을 지키기 위해 사용한다.
데이터베이스는 데이터를 영속적으로 저장하고있는 시스템이다. 이런 데이터베이스 시스템은 동시에 여러 사용자가 접근하는 상황을 피할수가 없는데, 이렇게 여러 사용자가 동시에 접근하게 되면 갱손 손실, 더티 리드, 불일치 읽기, 팬텀 리드등 다양한 문제가 발생한다. 이런 문제를 해결하기 위해 Lock을 사용하여 트랜잭션의 순차성을 보장한다.
공유락은 읽기 명령에 대해 주어지는 Rock이다. 앞글자를 따와서 주로 S Lock로 표기된다.
공유락은 여러 사용자가 동시에 접근해도 문제가 없어, 공유락끼리의 동시 접근을 허용한다. 하지만 공유락이 설정된 데이터에 베타 락을 사용할 순 없다.
베타 락은 쓰기 명령에 대해 주어지는 Rock이다. 앞글자를 따와서 주로 X Lock으로 표기된다.
공유 락은 여러 사용자가 동시에 접근해도 문제가 없는 반면에, 베타 락은 Lock이 걸린 대상을 제외한 다른 트랜잭션은 모두 읽기도, 쓰기도 막히게 된다.