2024. 2. 23. 19:50ㆍTIL
오늘은 발표자료 제작과 발표 및 KPT, 다면평가 위주로 진행되었다.
- KEEP
- 프로젝트 진행 중 생긴 문제를 원인 - 해결책 - 결과 순으로 잘 정리하였다
- 깃헙 프로젝트 같이 협업 툴 이용 적극적으로 하였다
- 문제를 해결할 때 팀원 모두가 참여하여 노력하였다
- PROBLEM
- 스핀락의 경우엔 락점유를 위해 계속 시도를 하는데 이 과정에서 만료시간의 정책이 필요하다
- 글로벌 락을 많이 쓰게 될텐데 Rpop Lpush 라는 것을 이용해보자
- 테스트 코드에서 벽을 느꼈다
- TRY
- 서버에 부하가 덜 가해지도록 시간정책을 구성하자!
- push(lpush, rpush)와 pop(lpop, rpop)을 적용해보자!
- 테스트 코드를 좀 더 연습해보자!
이후엔 개인공부시간을 가지다가 7시에 튜터님께 궁금한점을 하나 물어보았다.
우리는 락을 어노테이션으로 변경후에 락의 키를 구현할때 그 상품의 이름+ID 값을 가져와서 키로 만들었다.
그 이유는 키의 고유명사를 좀 다르게하기 위해서 이다.
좀더 풀어서 설명하자면..
하나의 가게에 상품이 2개가 있다고 치자.
이 두개의 상품은 둘다 한정수량이 있고 선착순은 따로 이뤄져야 하도록 정책을 짰다.
근데 둘다 키의 이름이 같아버리면? 상품2를 구매하려고할때 상품1이 락을 점유하고 있어서 못가져갈수도 있는 상황이 나올수 있다.
이 때문에 아이디값이라도 받아와서 키의 이름을 나누려는 것이다.
사실 해결방법에는 어노테이션 제작후에 @어노테이션("goods", 1)이런식으로 값을 넘겨주는 방법도 있지만
우리는 이 어노테이션에 넣어주는 값을 최소화 하고 싶었다.
그래서 우리가 내놓은 해결책은 어노테이션DTO를 도메인의 DTO가 상속받게 해서 DTO 속에서 값을 가져오는 식으로 만들었다.
그런데 튜터님이 알려준 방식으로는 @어노테이션이름(파라미터이름 = "#도메인파라미터이름") 이런식으로 파라미터이름을 비교해서 같은 이름을가진 파라미터의 값을 가져올수도 있다고 한다.
@SpinLock(id="#id")
이런식..
추가로 우리가 발표준비를 하면서 예상 질문 한개를 생각해보았다.
왜 redis를 썻는가?
1. redis가 싱글 스레드라서 다른 동시성 문제없이 이런 하나의 값만 들어가야하는 락을 구현하는데 적합했다.
2. pub/sub, spinlock 등 을 지원해서 여러가지 락을 구현해보며 연습할수 있었다.
가장 좋다고 생각되는 락은 무엇이였나?
pub/sub 기반 락
결과적으로는 pub/sub을 사용할것 같다.
다른 스핀락 방식과는 다르게 네트워크 리소스 소모가 가장 적을것 같아서
이번 프로젝트는 상당히 배워갈게 많은 주였다.
이제 최종프로젝트에서 얼마나 잘 써먹을지가 문제인것 같다.
'TIL' 카테고리의 다른 글
20240227 (화) 최종 프로젝트 티켓레이더 1주차 - 회의 진행 중.. (0) | 2024.02.27 |
---|---|
20240226 (월) 최종 프로젝트 티켓레이더 1주차 (0) | 2024.02.26 |
20240222 (목) 대용량 트래픽 프로젝트 - 동시성 제어 프로젝트 7일차 (0) | 2024.02.22 |
20240221 (수) 대용량 트래픽 프로젝트 - 동시성 제어 프로젝트 6일차 (0) | 2024.02.21 |
20240220 (화) 대용량 트래픽 프로젝트 - 동시성 제어 프로젝트 5일차 (1) | 2024.02.20 |