멘토링 날짜 : 2024년 2월 7일 수요일 오전 10:10
이번 주 한 일
•
팀원 개인
김재윤
임지훈
장규빈
황규정
질문 정리
•
[김재윤] 오픈소스 기여를 해보고 싶은데 (바쁘면 취업 이후로), 저와 같은 신입 개발자가 도전할 만한 범위나 분야가 있을까요? (우선 생각해둔 레포로는 spring data redis가 있습니다 하하,,)
◦
오픈소스 커미터.. 스프링 진영에서는 불가능 ㅠㅠ
◦
스프링 오픈 소스 이지만, 컨트리뷰터는 특정 재단에서 해서 일반 사용자는 불가
•
[임지훈]
1.
SpringBoot의 Retry를 사용하게되면 트랜잭션과 동일한 스레드를 재사용하게 되어서 성능 상 이슈가 있다고 생각합니다. 튜터님의 의견이 궁금합니다.
•
Request를 다시 보내거나, Batch를 돌리는 게 나을 듯
특정 부분의 메서드 재사용시, 아래와 같은 단점 존재
•
성능 상 이슈
•
데이터 정합성이 꺠질 가능성
2.
JPA의 Dirty Checking 에 대해서는 Pessimistic Lock 을 걸지 않아도 될까요? MySQL의 MVCC로 제어가 가능한 부분인지 궁금합니다.
•
입찰에 의한 주문 시나리오에서, JPA의 Dirty Checking 에 의한 구매자,판매자의 Point 증감 처리
BuyBidProvider.java
SellNowProvider.java
BuyNowProvider.java
•
아무리 테스트 해도 구매자,판매자의 포인트 증감에서는 에러가 나지 않아, MVCC로 제어되는거구나 넘겨짚었는데 확실치가 않습니다.
BuyNowConcurrentTest.java
SellNowConcureentTest.java
3.
Pub/Sub 구조로 리팩터링한 페이먼츠 개발이 굉장히 어색하다고 느껴집니다. 튜터님의 의견이 궁금합니다.
•
ApplicationPublisher를 통해 분산서비스에 대한 Event Handler를 분리했습니다.
•
Pub/Sub 구조는 One-way 식 코드패턴입니다.
•
하지만 페이먼츠 구조는 Two-way 로 처리됩니다.
•
왜냐하면 페이먼츠는 특성 상 결제 상태에 따른 비즈니스 처리가 상당히 많이 필요하기 때문입니다.
◦
결제 이전 비즈니스 로직, 결제 중 비즈니스 로직, 결제 후 비즈니스 로직
◦
이에 따라 결국 이벤트 핸들러 또한 비즈니스 로직 처리를 하게 되었습니다.
•
하지만 분사서비스 호출과 비즈니스를 분리하게 된다면, 에러 발생에 따른 롤백처리가 어려워집니다.
페이먼츠는 따로 모놀리식으로 분리해서 분산서비스를 받아주도록 하자.
•
Message Queue 를 사용하여 페이먼츠를 처리
•
페이먼츠만 단일 엔드포인트를 사용하여 트랜잭션 관리를 분리
4.
•
어필할 부분
◦
내가 어필하고 싶은 부분과 면접관이 관심있는 부분과 상당히 차이가 있을 수 있다. → 노력이 필요. 채용 공고를 보며 우대사항이나 자격 요건 등을 보며 원하는 내용을 우선 확인하고, 프로젝트에서 해당 부분을 찾아서 작성하기
◦
프로젝트 전반적으로 어필할 만한 부분
▪
데드락 동시성 이슈 문서. 아직 완성은 안 됐지만, 어필할만한 부분.
▪
pub/sub, cascade, cqrs 적용기 등 글 괜찮.
숙제: 멘토링 결과 및 다음 주까지 해올 일
•
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
◦
•
팀원 개인별로 작성해 주세요.
•
이외에도 기술적인 방향을 잡기 위한 질문을 정리해두시면 가장 좋습니다!
→ 단, “A는 어떻게 구현하나요”의 질문은 삼가주세요.
→ “A와 B를 알아보았는데, 둘 중 A가 낫다고 판단했는데 맞을까요?”의 식의 고민의 흔적을 담아 질문해주세요.
•
멘토링 결과:
