알림 처리를 위해 필요한 인프라는?
스터디가 만들어지거나 스터디에 대한 정보가 바뀌거나 참가 신청했던 것에 대한 변경이 생길 시 추가적인 알람을 보내는 것이다. 알림을 받을 때 웹, 이메일 등으로 받을 수 있다. 근데 이 일 자체가 부가적인 일이고, 메인 로직에 영향을 주고싶지 않다. 응답 시간에도 영향 X, 트랜잭션에도 영향을 주고 싶지 않다. 따라서 비동기적 방법을 이용하자. 알림이 서비스 로직에 영향을 주지 않도록 정리하자.
스프링이 제공하는 ApplicationEventPublisher와 스프링 @Async 기능을 사용해서 비동기 이벤트 기반으로 알림 처리.
- 주요 로직 응답 시간에 영향을 주지 않기.
- 코드를 최대한 주요 로직에 집중하고 알림 처리 로직은 분리.
스터디 new -> test4
test4 스터디를 만들지 못하고 rollback 된다. (같은 스레드에서 돌기 떄문에)
첫번째 스레드는 끝나고 커밋됨.
두번째 스레드가 아무리 에러를 던져도 영향을 주지 않도록!
Notification 부가적인 시도로 처리하고 싶기 때문
스레드를 분리, 만약 이메일을 보냈는데 시간이 오래걸린다. 그럼 스터디를 생성할 때 한참 기다려야 할 것이다. 그렇게 기다릴 필요가 없다.
등의 여러가지 의미로 async를 적용하는 게 편한 상황이라고 생각했다.
코드가 같았는데 이번에 test4가 만들어졌다. error도 스레드에서 던지는 것, 이 에러를 처리하는 핸들러를 등록할 수 있다. AsyncConfigurer!
ThreadPoolTaskExecutor
자바에 스레드풀~ 이 있다.
기본값 셋팅,
ThreadPoolTaskExecutor
- https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/scheduling/co
ncurrent/ThreadPoolTaskExecutor.html - CorePoolSize, MaxPoolSize, QueueCapacity
- 처리할 태스크(이벤트)가 생겼을 때,
- ‘현재 일하고 있는 쓰레드 개수’(active thread)가 ‘코어 개수’(core pool size)보다 작으면
남아있는 쓰레드를 사용한다. - ‘현재 일하고 있는 쓰레드 개수’가 코어 개수만큼 차있으면 ‘큐 용량’(queue capacity)이
찰때까지 큐에 쌓아둔다. - 큐 용량이 다 차면, 코어 개수를 넘어서 ‘맥스 개수’(max pool size)에 다르기 전까지
새로운 쓰레드를 만들어 처리한다. - 맥스 개수를 넘기면 태스크를 처리하지 못한다.
애플리케이션 입장에서 event는 task이다. 새로운 이벤트가 들어왔으면 StudyEventListener가 Async하게 처리해야 한다.
StudyEventListener가 튜브라고 생각하고 각각 들어오는 이벤트가 사람이라고 생각하면 된다. 새로 사람이 pool장에 들어왔는데 pool장에 튜브가 10개밖에 없다.
출처 : 인프런 백기선님의 스프링과 JPA 기반 웹 애플리케이션 개발
