개발자국

스프링부트는 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..

테스트 종류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..

빈페이로 결제하게 된 이유서비스내의 결제 로직과 외부 API를 통한 충전로직을 분리함으로 써 외부 API에서 발생했을때 문제와 결제 기능과 분리할 수 있기 때문입니다! 또한 결제를 진행하는 중에는 외부API를 연동하지 않기 때문에 사용자의 경험을 향상시키고 결제 프로세스를 간소화할 수 있습니다.서비스 자체 포인트인 빈페이를 관리하는 방법유저 MSA에 beanpay 컬럼을 두어 결제 MSA API 요청을 통해 관리한다.결제 MSA에 BeanPay 테이블과 BeanPay 상세 테이블을 두어 관리한다.1. 유저 MSA에 beanpay 컬럼을 두어 결제 MSA API 요청을 통해 관리한다.결제 MSA에서 출금, 결제, 환불, 사용 과 같은 행위를 할 때 유저 MSA에게 요청을 하고 로직을 수행합니다. 하지만 이..