Redis - Lettuce Lock

• Lettuce는 기본적인 동기 / 비동기 통신과 데이터 조작에 최적화 되어 있음
• 분산 락을 구현하긴 했지만 Key를 사용한 통신을 통해 데이터를 제어하게 구현했을 뿐임
• 프로젝트에서 쿠폰 발급에 사용한 SpinLock은 지속적으로 락 획득 요청을 보내기 때문에 Redis에 부하를 더 가하게 됨
• Unlock이 되지 않은 채 어플리케이션이 종료되면 무한루프에 걸릴 수 있음

Redis - Redisson Lock

• Redisson은 Pub/Sub을 이용해 락의 획득을 제어함
• Redisson client의 tryLock 을 통해 분산 락을 제어
  성공시 락을 획득해 로직 진행, Unlock시 Pub
• 실패하면 Sub에 등록후 Unlock 이벤트 발행까지 대기함
• 다만 내부적으로 완전히 SpinLock의 구조를 가지지 않은 것은 아님
• Lock 점유 시간을 확인하고 구독의 유효시간등을 체크하느라 무한루프를 돌게 됨

MySQL - Optimistic lock

• 낙관적 락은 버전 정보를 기록해서 커밋 시점에 다른 트랜잭션이 해당 버전에 대해 수정을 진행했는지 체크를 진행함
  @Version
• 커밋 시점에 버전을 체크하기 때문에 수정에서 일관적이지 않은 결과를 제공하는 대신 조회에서는 빠른 퍼포먼스를 제공함
• 트랜잭션의 충돌이 일어날 확률이 적을 때 사용하면 성능적으로 이득을 볼 수 있음

MySQL - Pessimistic Lock

• 비관적 락은 데이터의 동시 접근을 제어하기 위해 아예 DB에서 잠궈버려 다른 트랜잭션이 접근 못하게 함
  @Lock
• 데이터 변경 시점에서 즉시 잠궈버리고 트랜잭션 완료때 해제되기 때문에 데이터 일관성을 보장함
• 교착 상태가 길어지면 DB 자체의 성능이 저하되고 트랜잭션이 복잡해지면 데드락 상황이 발생할 수 있음
• 티켓만 발급하는 간단한 시스템에 한개의 티켓에 대해서만 테스트를 진행해서 MySQL이 가장 빨라보이지만 단점이 있음
  남발하게 되면 데드락의 위험성이 높아짐
  • 시스템 리소스의 추가적인 사용
  • 요청이 많아질수록 오버헤드 발생
• 쓴다면 낙관적 락, Named Lock, Exclusive 대신
  쓰기만 방지하는 Shared 같은 락 정책도 고려해봐야 함
• DB의 스케일아웃 시점에서는 무용지물임

프로젝트에서의 결론

현재 시나리오(간단한 쿠폰 발급만 하는 단일 시스템)에서 초당 처리량은
Lettuce < Redisson <= MySQL
Lettuce와 나머지는 2배가량 차이

다만 추후 확장성과 안정성을 고려하면 Redisson을 사용하는 것이 좋아보임