서론 exactly-once message delivery 과정에서 어떤 문제가 생길 수 있는지 알아보고 kafka transaction 처리가 어떤 방식으로 그 문제를 해결하는지 알아보자. 해당 글에서 write-produce와 read-consume은 서로 같은 의미로 썼습니다. 왜 transaction이 필요할까? 점차 많은 사람들이 카프카를 사용하면서 read-process-write 과정에서 exactly-once 기능의 지원을 필요로 했다. A 메세지의 consume이 B 메세지의 publish라는 필요충분 조건을 만족시켜야 했다는 말이다. 일반적인 at-least-once 프로듀서와 컨슈머로는 다음 상황들로 인해 exactly-once read-process-write(rpw)을 만족시키는 application을 만들 수 없다. producer의 중복 요청 : 이는 위에 언급한 producer에서 멱등성 유지를 위한 sequence 번호 부여로 해결가능하다.

기존 상황 n+1 쿼리를 db 호출 로그를 통해 육안으로 확인하고 있었습니다. 목적 테스트를 통해서 n+1 쿼리를 빠르게 방지할 수 있는 방법을 찾고 싶습니다. 해결 방안 datasource-proxy 라이브러리를 통해 실행한 쿼리문의 개수를 불러와서 예상한 쿼리문의 수와 맞는지 비교합니다. 설정 build.gradle.kts에 다음과 같은 내용을 dependencies에 추가합니다. implementation("net.ttddyy:datasource-proxy:1.7") 그리고 spring-boot에서 proxybean을 생성하게 위해서 BeanPostProcessor를 하나 만들어서 등록해줍니다. 테스트에서만 사용할 거라 적절한 @Profile도 붙여줍니다. @Configuration @Profile("test") class DatasourceProxyBeanPostProcessor : BeanPostProcessor { override fun postProcessAfterInitialization(bean: Any, beanName: String): Any?