Feature/nyh365 step4 #34
Conversation
- 다중환경에서 lost update로 인한 데이터 적합성 문제를 해결하기 위해 락을 사용했습니다. - 은행 업무에서는 데이터 무결성을 지키는게 중요하다고 생각해서 비관적 락을 사용했습니다.
- 다중 환경에서 lost update로 인한 데이터 무결성 해결을 위해 비관적 락 사용
- 이후 확장성을 위해 int에서 long으로 변경
- 이후 확장성을 위해 int에서 long으로 변경
- 송금 내역 저장을 위함 - 메세지 큐에 메세지 전송을 위함
- 이벤트 리스너가 비동기적으로 실행되도록 하기 위함
- 이벤트 리스너를 통해 수령인의 잔액 업데이트 로직 분리 - 메세지 큐를 통해 수령인의 잔액 업데이트
- 지연 송금, 즉시 송금 이벤트 분리
- 향후 상세 로직 및 보완 예정
- 한번에 검증을 수행하는 것이 아닌 각 업데이트마다 검증하도록 변경 - 불필요한 쿼리 수행 제거
| AND t.type = :type | ||
| AND t.createDate = :targetTime | ||
| """) | ||
| List<TransferTransaction> findPendingTransactions(@Param("status") TransactionStatus status, |
There was a problem hiding this comment.
t.createDate = :targetTime처럼 동등조건으로 필터링한 이유가 있을까요? 스케줄러가 돌고 그 다음 스케줄러가 도는 그 빈 시간동안 데이터가 누락될 것 같은 느낌이 들어요
There was a problem hiding this comment.
알림 전송 여부를 아직 추가를 못한 상태라 중복 발송될 것이라 생각해 임시로 동등 조건으로 해두었습니다. 알림 관련 기능 추가 후 범위 조건으로 변경할 예정입니다.
| } | ||
|
|
||
| @Transactional | ||
| public void acceptTransfer(Long transferTransactionId, TransferAcceptReq transferAcceptReq) { |
There was a problem hiding this comment.
메시지 큐를 사용한 이유가 A->B로 송금 시 1. 락을 가지고 A 계좌 잔액 차감 2. 송금 내역 추가 3. B 계좌 잔액 증액 인데 트랜잭션이 길다 보니 3번 과정을 분리하기 위해 사용했었습니다. 근데 해당 기능에서는 2번과 3번의 과정만 거치기 때문에 따로 메시지 큐를 사용하지 않았습니다.
| @Slf4j | ||
| @Service | ||
| @RequiredArgsConstructor | ||
| public class TransactionService { |
There was a problem hiding this comment.
해당 기능을 따로 추가 못했습니다. 반영해서 올리겠습니다.
|
|
||
| @Transactional | ||
| public void acceptTransfer(Long transferTransactionId, TransferAcceptReq transferAcceptReq) { | ||
| TransferTransaction transferTransaction = transferTransactionRepository.findByIdAndStatus(transferTransactionId, |
There was a problem hiding this comment.
현재 update 쿼리를 이용해서 accept, cancel 처리를 하고 있습니다. 동시에 accept, cancel 요청이 온다면 둘 중 하나는 transaction status가 update 조건에 해당하지 않아 update를 못하게 되고 이후 검증 로직에서 오류를 던져 롤백하도록 구현했습니다.
|
|
||
| List<TransferTransaction> transferTransactions = transferTransactionRepository.getTransferTransactionsByStatusAndType( | ||
| TransactionStatus.PENDING, TransactionType.IMMEDIATE); | ||
|
|
There was a problem hiding this comment.
해당 함수가 메시지큐에서 송금처리가 제대로 되지 않았을 경우에, 비정상 송금 내역을 찾아서 다시 메시지큐에 넣는 함수로 이해했는데,
그렇다면 해당 이벤트를 다시 발행하는 동안 송금 취소 트랜잭션이 실행되면 어떻게 되나요??
There was a problem hiding this comment.
메시지를 처리할 때 들어온 메시지(비정상 송금 내역)가 조건에 해당하는지(송금 취소 안된 송금 내역인지) 확인하는 로직이 있습니다. 그래서 메세지를 처리하는 동시에 송금 취소 트랜잭션이 실행되어도 둘 중 하나만 처리되도록 구현한 상태입니다.
구현 요구 사항
구현
보완해야할 부분