Today I Learned ...
오늘도 코드카타는 생각도 못했고,,, Ticketing Service 팀프로젝트의 도전 기능을 시작했다!
🖥️ Ticketing Service 팀프로젝트 #3
오늘은 완성된 v1에 이어 동시성 제어와 Redis 캐싱, 쿼리 최적화, 배포와 CI/CD 등 도전 기능을 구현하기 시작했다.
나는 이 중에서 동시성 제어 파트를 맡았는데, 티켓팅 서비스인 만큼 자리 예매에 대한 동시성 제어가 가장 중요했다.
일단 비관적 락과 낙관적 락, 분산 락에 대해서 알아보고 각각의 장단점을 찾아보았다.
나는 처음에 낙관적 락과 분산 락 사이에서 고민을 했었는데, 알고보니 낙관적 락은 이렇게 충돌이 많은 경우에는 사용하지 않는다고 하더라.
그래서 결국 분산 락으로 1차적으로 동시성 이슈를 제어한 뒤, 비관적 락을 통해 데이터가 수정되는 순간을 한 번 더 보호하기로 결정하였다.
각각의 내용에 대해 조사한 자료는 노션을 통해 정리해두었다.
Notion 확인하기
Redis를 통한 분산 락을 구현할 때, Lettuce와 Redisson, 2가지 방법으로 구현할 수 있다.
과제 발제 문서에 필수 구현으로 Lettuce만 사용하여 구현하고, 도전 기능으로 Redisson을 사용하라고 되어있더라.
그래서 오늘은 우선 Lettuce를 통해 Redison Lock을 구현하였다.
지난 강의를 들을 때 Lettuce로 Redison Lock 구현 실습을 진행했기 때문에, Lock 자체를 진행하는 데에는 큰 문제가 없었다.
다만, 동시성 이슈가 생기는 시나리오를 기반으로 테스트 코드를 작성하는 데에서 조금 고민할 부분들이 있었다.
기존에는 ExecutorService를 사용해서 진행했지만, 이번에는 CountDownLatch라는 새로운 객체를 사용해보았다.
CountDownLatch는 여러 쓰레드에서 작업이 완료 될 때까지 대기하도록 Sync를 맞춰주는 기능을 제공하는데, 이를 통해서 완전히 동시에 여러 쓰레드의 작업이 실행되도록 지정할 수 있다고 한다.
이에 대한 내용은 이후에 더 자세히 작성해보아야겠다.
작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
오늘 내용들을 진행하면서 정말 플러스 주차가 맞다는 생각이 들었다.
동시성 제어라는 하나의 파트만 맡아서 진행할 뿐인데도 생각해야 할 부분들이 너무 너무 많았다.
빨리 이런 저런 내용들을 공부하고 정리해보아야겠다.
