개발자국

스프링부트는 ThreadPool을 통해 스레드를 미리 생성하고 요청에 맞게 쓰레드를 배정하고 응답이 끝나면 쓰레드를 반환합니다.저는 이 쓰레드를 이용해 인증을 통과한 사용자일 때 ThreadLocal에 사용자의 ID를 삽입하여 전역적으로 사용할 수 있게 하려고 했습니다.문제점 발생!!하지만 처음에 인증에 성공하여 ThreadLocal에 저장되고 초기화 하지 않았을 때 다음 사용자가 인증에 실패해도 전에 사용자의 정보가 남아있어 비즈니스 로직이 실행되는 문제가 발생했습니다.아래 예시들을 통해 설명드리겠습니다.1번 요청의 사용자는 1이라는 값을 통해 인증을 수행합니다.인증 로직을 통과하고 전역적으로 사용할 수 있는 쓰레드에 1이라는 값을 저장합니다.1번 사용자가 요청한 비즈니스 로직을 끝맡히고 쓰레드풀에 쓰..

InMemory 인증번호 관리회원가입을 할 때 핸드폰 번호로 인증번호를 전송하고 인증번호를 통해 회원을 검증했습니다.인증번호 발행랜덤 번호를 생성하고 휴대폰으로 랜덤번호를 전송하고 Map 번호를 저장하는 방식입니다.인증번호 검증현재 인증시간이 유효한지 확인하고 인증번호를 검증합니다. 인증번호가 일치하면 Map에서 key를 제거하지만 인증번호가 일치하지 않는다면 계속해서 메모리에 남아있게 됩니다.인메모리로 관리하는 key관리시 메모리 Leak 발생key를 요청하고 검증을 하지 않았을 때 계속해서 데이터가 Map에 참조하고 있어 GC가 메모리를 수거하지 않습니다.해결방법@TimeTrace @Scheduled(cron = "0 10 * * * *") public void clearAuthentica..

변경 전 테이블 구조BeanPayDetail 역할BeanPayDetail의 역할은 기존의 빈페이의 변경 내역에 관한 정보를 담고 있었습니다.총 4가지의 역할을 갖고 상태값을 통해 나누어서 사용했습니다.충전지출입금출금PaymentDetail 역할PaymentDetail 역할은 세부 결제 내역 정보를 담고 있으며 PaymentStatus로 상태값을 나누어 관리합니다.결제환불중복된 컬럼변경 이유PaymentDetail과 BeanPayDetail의 진행 상태인 ProcessStatus 값이 중복되어 사용됐습니다.BeanPayDetail의 추가적인 Row를 생산하지 않을 수 있습니다.로직이 하나의 Depth가 줄어들고 유지보수성이 높아졌습니다.기존의 복잡했던 연관관계가 줄어들었습니다 BeanPayDetail은 B..

주문/결제, 동기/비동기 처리에 대한 고민저희는 충전 API와 결제 API가 분리되어 있어 주문 -> 결제 로직이 실행될 때는 토스 외부 API에 영향을 받지 않습니다. 그렇기 때문에 주문이 발생함과 동시에 결제도 같이 처리될 수 있었습니다.그래서 저희는 3가지 방식을 생각했습니다.첫번째 주문 API에서 모든 로직을 동기로 처리하는 것 입니다. (동기)두번째 는 주문 API와 결제 API를 분리하는 것 입니다. (동기)세번째 는 주문 API에서 결제 API까지 처리하는 것 입니다. (부분 비동기) 첫번째는 주문 API에서 모든 로직을 동기로 처리하는 것 입니다. (동기)시퀸스 다이어그램을 보시면 Order MSA에서 모든 로직이 수행되며 다른 MSA를 호출하여 로직이 수행됩니다.한번에 모든 MSA에게 요..

테스트 종류1. 락 X 트랜잭션 사용2. Beta Lock 사용3. Redisson 분산락 사용총 3가지의 테스트를 했습니다. 각각의 코드에서 발생할 수 있는 문제점, 걸린 시간, 특징에 대해서 작성했습니다.테스트 환경DB: H2Mode: MariaDB테스트 환경: LocalReids: Embedded요청 스레드 수 : 32요청 횟수 : 각 1회Transaction을 사용하여 동시성 테스트 결과코드 본문@Transactional public void notUseLockTest(String lockName, Integer userId) { BeanPay beanPay = getBeanPay(1, Role.USER); final BeanPayDetail beanPayDetail = Bea..