[재고시스템으로 알아보는 동시성 이슈 해결방법] #4 Pessimistic Lock 비관적 락 , Optimistic Lock 낙관적 락, Named Lock 1

들어가기 전...

1. 이전 게시글과 이어지는 게시글이므로 프로젝트 환경 및 세팅은 아래 링크에서 확인해주세요!
2. 전체 코드는 아래의 Git에서 확인 가능합니다.
 

[재고시스템으로 알아보는 동시성 이슈 해결방법] #3 synchronized 와 문제점

 

GitHub - dev-rosieposie128/stock: 재고시스템으로 알아보는 동시성이슈 해결방법

 

지난 게시글에서는 자바에서 지원하는 sychronized를 사용하여 해결하는 방법을 알아보았다! 

이번에는 MySQL이 지원하는 다양한 Lock의 개념을 알아보고 그 차이를 알아보자!

목표

• Pessimistic Lock - 비관적 락을 이해한다.
• Optimistic Lock - 낙관적 락을 이해한다.
• Named Lock

Pessimistic Lock - 비관적 락

자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론

• 트랜잭션의 충돌이 발생한다고 가정
• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 한다.
• 데이터베이스에서 Shared Lock(공유, 읽기 잠금) 이나 Exclusive Lock(배타, 쓰기 잠금) 을 건다.
• Shared Lock 의 경우, 다른 트랜잭션에서 읽기만 가능하다. 또한 Exclusive lock 적용이 불가능하다. (읽는동안 변경하는것을 막기 위해)
• Exclusive lock 의 경우. 다른 트랜잭션에서 읽기, 쓰기가 둘다 불가능하다. 또한 Shared, Exclusive Lock 적용이 추가적으로 불가능하다. (쓰는동안 읽거나, 다른 쓰기가 오는것을 막기위해)

비관적 락

• 서버가 여러대가 있을 때, 서버1이 락을 걸고 데이터를 가져가게 되면 서버 2,3,4,5는 서버 1이 락을 해제 하기 전까지 데이터를 가져갈 수 없다.
• 데이터 무결성 수준이 높다

=> 데이터에는 락을 가진 스레드만 접근할 수 있으므로, 문제 해결이 가능하다.

 

그러나,

• 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러진다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있다.

Optimistic Lock - 낙관적 락

자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론

• 트랜잭션의 충돌이 발생하지 않을것이라고 기대
• 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리
• 먼저 데이터를 읽은 후에 update를 수행할 때 현재 내가 읽은 버전이 맞는지 확인하여 업데이트 한다.
• 내가 읽은 버전에서 수정사항이 생긴 경우, DB단에서 동시성을 처리하는것이 아닌, 어플리케이션단에서 처리 한다.

낙관적 락

• 서버1과 서버2가 데이터베이스에서 버전 1인 role을 읽어왔다.
• 읽고 난 이후 서버1이 먼저 업데이트 쿼리를 날린다.
• 업데이트 쿼리를 수행할 때 where 조건에 버전 1인걸 명시를 해주면서 업데이트 한다.
• 그러면 실제 데이터는 버전 2가 되게 된다.
• 그리고 서버 2가 이후에 동일하게 업데이트 쿼리를 수행한다.
• 마찬가지로 현재 읽은 버전을 업데이트 하는 조건이 포함되어 있기 때문에 업데이트는 수행이 되지 않는다.
• 왜냐하면 현재 읽은 버전은 버전이 1이고 실제 데이터는 버전이 2인 상태이기 때문이다.
• 업데이트가 실패하게 되면서 실제 어플리케이션에서 다시 읽은 후에 작업을 수행해야 하는 로직을 넣어줘야 한다. 
• 여러 작업이 묶인 트랜잭션으로 요청이 간 경우가 실패한경우, 개발자가 직접 롤백 처리 를 해줘야 한다.

=> 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

 

그러나,

• 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

Named Lock 

이름을 가진 metadata locking이다. 이름을 가진 lock을 획득한 후 해제할 때까지 다른 세션은 이 lock을 획득할 수 없도록 한다.

주의할점으로는 transaction이 종료될 때 lock이 자동으로 해제되지 않는다. 별도의 명령어로 해제를 수행해주거나 선점시간이 끝나야 해제된다.

 

 

 

 

참고

https://unluckyjung.github.io/db/2022/03/07/Optimistic-vs-Pessimistic-Lock/

낙관적(Optimistic) 락과 비관적(Pessimisitc)락

https://www.inflearn.com/course/%EB%8F%99%EC%8B%9C%EC%84%B1%EC%9D%B4%EC%8A%88-%EC%9E%AC%EA%B3%A0%EC%8B%9C%EC%8A%A4%ED%85%9C/dashboard

재고시스템으로 알아보는 동시성이슈 해결방법 - 인프런 | 강의