최초의 쿠폰 발급(선착순) Logic 문제점(Redis 적용 전)

레이스 컨디션이 발생하는 곳 : 쿠폰 갯수를 가져오는 부분

하지만, 쿠폰 발급 전체를 싱글 스레드로 작업한다면, 성능이 좋지 않을 것이다.

먼저 요청한 사람의 쿠폰이 발급된 이후에 다른 사람들의 쿠폰 발급이 가능해지기 때문이다.

아래 예시를 보자.

예시)
10:01 1번 사용자 쿠폰 요청
10:03 1번 사용자 쿠폰 발급
→ 2~N번 사용자는 10:03까지 기다려야 한다.

synchronized : 하나의 서버에만 보장되고, 여러 서버에서는 보장되지 않는다.

mySql redis를 활용한 Lock : 하지만, 우리가 원하는건 쿠폰 갯수에 대한 정합성인데 Lock을 활용하여 구현한다면,
발급된 쿠폰 갯수를 가져오는 것부터 쿠폰을 생성하는 것까지 Lock을 걸어야함. → 성능 저하. 위의 예시와 비슷함.

table 단위로 lock을 걸기 때문이다.

핵심 : 쿠폰 갯수의 정합성

Redis에는 incr이라는 명령어가 존재하고, 이 명령어는 Key에 대한 value를 1씩 증가시키는 명령이다.

Redis는 싱글 스레드 기반으로 동작하여, 레이스 컨디션을 해결할 수 있을 뿐 만 아니라 incr 명령어는 성능이 좋다.
(즉, 성능도 빠르며, 데이터 정합성도 지킬 수 있다.)

 

간단한 실습

https://hsdevelopment.tistory.com/832

Redis incr 간단한 실습

 

 

 

참고사항

https://www.inflearn.com/questions/952111

MySql Lock을 사용하지 않는 이유 - 인프런 | 질문 & 답변

 

MySQL에서 lock을 사용하는 이유는 동시에 여러 개의 트랜잭션이 같은 데이터를 수정하려고 할 때 데이터의 일관성을 유지하고 충돌을 방지하기 위해서입니다.

쿠폰 갯수를 가져오는 작업에서도 lock을 걸어야 하는 이유는 여러 개의 트랜잭션이 동시에 해당 데이터를 읽을 경우, 잘못된 값을 읽는 문제가 발생할 수 있기 때문입니다.

 

따라서, lock을 사용하여 동시에 여러 개의 트랜잭션이 해당 데이터를 읽지 못하도록 막고, 일관성을 유지할 수 있습니다.

다만, table에 lock을 걸게 되면 다른 트랜잭션들이 해당 테이블의 다른 데이터에 접근할 수 없기 때문에 성능 이슈가 발생할 수 있습니다. 성능 이슈는 lock이 걸린 시간 동안 다른 트랜잭션이 대기해야 하기 때문에 발생합니다.

따라서, lock을 사용할 때는 성능 이슈를 고려하여 효율적으로 사용해야 합니다.

 

예를 들면, 필요한 데이터만을 lock을 걸고 나머지 부분에 대해서는 lock을 풀어주는 방법을 사용하거나, lock 대기 시간을 최소한으로 줄이기 위해 빠른 처리가 가능한 작업에 대해서만 lock을 사용하는 등의 방법을 고려할 수 있습니다.

하지만, 성능 이슈가 너무 크다면 다른 방법을 사용하는 것도 한 가지 방법입니다. 

 

예를 들면, MySQL에서는 SELECT 문과 INSERT 문을 같은 트랜잭션 안에서 사용할 때 암묵적으로 lock을 걸어주는 기능인 격리 수준(Isolation level)을 조정하는 방법도 있습니다.

결론적으로, lock을 사용할 때는 성능 이슈를 고려하여 적절하게 사용해야 하며, 성능 문제가 심각하다면 다른 방법을 사용할 수도 있습니다. 

 

성능 최적화에 대한 고민이 필요한 경우에는 성능 테스트를 통해 최적화를 진행하거나, DBA(DB 관리자)의 도움을 받아서 문제를 해결해보시는 것을 추천드립니다.