Redisson3 [Refactor] 패키지 구조와 의존성 두 번째 프로젝트의 코드 작성이 거의 끝났고, 테스트 코드 작성을 앞두며 코드 리뷰를 받았다. 가장 큰 골자는 아무래도 참조 관계이다. 패키지 구조를 Layered에서 약간의 DDD(애매하지만 ㅎㅎ) 를 곁들인 구조로 변경했다. 그 과정에서 패키지 간 의존성에 대해서 고민해보고 작명하는 것과 설계하는 시간이 정말 오래 걸렸다. 코딩을 공부하면 할 수록 작은 것에 시간을 오래 들이게 되는 걸 느낀다. 어제는 패키지 이름을 짓는데 반나절이 걸렸다. 회사에서는 변수명 짓는 걸로도 회의를 한다고 하니 약간 실감이 나기도 한다. 이렇게 디테일하게 채워나가면 그 만큼 내 실력이 된다고 믿습니다. 최상위 구조 auth : 인증, 인가 처리 스프링 시큐리티 이용 스프링 컨테이너까지 도달하지 않는 필터 위주이기 때문에 .. 2022. 10. 14. [Redisson]을 이용한 분산 Lock 구현 & 동시성 문제 해결 내 프로젝트의 Payment를 개발하면서 가장 기본 중에 기본이 되는 문제를 직면했었다. 그것은 바로 동시성 문제! 스프링부트의 내장 서버는 기본적으로 톰캣, 언더토우 등등의 WAS로 돌아가는데 이 WAS는 멀티스레드 기반으로 동작한다. A라는 상품 (재고 3개) 을 [가]군이 2개 구매하려 한다. 동시에 [나]군이 2개 구매하려 한다. 미세하게 나마 0.00001초의 차이가 있을 수 있다. 결국 각각의 스레드가 같은 상품의 재고를 조회한다. 원래대로라면 한 명은 못 사야 정상이다. 위 문제를 해결하기 위한 방법이 뭐가 있을까? 1. Synchronized 자바로 해결하는 방법이다. Thread-Safe 하기 때문에 매우 좋아보이나, 서버가 증설될 경우 의미가 없어진다. 2. Database Lock D.. 2022. 9. 27. 동시성 조회 문제 해결 및 성능에 관한 고민 [Lock, Queue, Redis] 주문 건에 대한 상품 재고 파악 동시성 관련 이슈에 대해 고민한 하루다. 프로젝트 리팩토링을 시작하며 지난 도메인들은 기본 crud API만을 다루었다. 5일동안 JPA 강의들을 수강하며 본격적으로 주문 및 결제 API 리팩토링에 다시 착수했다. 아무래도 프로젝트의 토픽이 쇼핑몰이니 주문 및 결제 파트에서 단순 CRUD가 아닌 핵심 비즈니스를 고려하고 싶어, 외부 결제 API 및 디자인 패턴을 적용한 깔끔한 코드들을 고려하며 작성하는 중이다. 대략적인 틀을 만든 뒤, 본격적으로 주문을 구현하던 중, 동시성 이슈 문제에 직면했다. 기존 동시성 문제 해결 방법 MSA를 고려했기에, 데이터 정합성 문제를 해결하기 위해 Outbox pattern을 이용중이었다. 이 방식을 통해 상품 동시성 문제를 해결했었다. .. 2022. 9. 14. 이전 1 다음 반응형
