NamedLock 테스트 실패

jaeyun0507 님 안녕하세요!테스트코드의 newFixedThreadPool 의 스레드 개수를 32개로 조절해보고 해주실 수 있으실까요?지금 현재 코드로 보았을때는 100개의 스레드가 동시에 요청을 하여 커넥션 고갈이 일어나고 있는듯합니다.

카프카를 도입하고 난 뒤 로그로 보여지는 장점을 발견하지 못하고 있습니다.

창신동 장첸님 안녕하세요.답변이 늦어져서 죄송합니다.강의에서는 카프카를 중간에 배압조절을 위한 장치로 사용하였습니다.1만명의 사용자가 동시에 요청을 보낸다고 가정해보겠습니다.API 에서 바로 DB 에 insert 를 하게 되면 1만번의 요청이 거의동시에 DB 에 요청을 보내게 됩니다.동시에 많은 요청은 DB 에 부담을 줄 수 있습니다.카프카로 메시지를 전달하고 순차적으로 처리를 하여 1만번의 요청을 순차적으로 처리하여 DB 에 부담을 줄일 수 있습니다.위와같은것이 가능한 이유는 카프카는 메시지를 토픽에 적재한 후 먼저 적재된 메시지를 처리한 이후에 다음 메시지를 처리하기 때문입니다.따라서, DB에 보내는 요청을 분산시킬 수 있게됩니다.궁금하신점이 있다면 질문 부탁드립니다!감사합니다.

사용자 동선에 대한 트랜잭션 문의

아무도_모를_아이디님 안녕하세요.답변이 늦어져서 죄송합니다.말씀하신대로 실제 쿠폰발급까지 비동기이기때문에 말씀하신대로 쿠폰을 바로 사용하기는 어려울 수 있습니다.두가지 방향이 있을 것 같습니다.비동기이기지만 준실시간이기 때문에 특별한 상황이 아니라면 문제가 되지 않을 확률이 높습니다. 문제가 되지 않을 수 있다면 감수하고 해당 아키텍쳐를 선택할 수 있습니다.약간의 딜레이가 용납되지 않는다면 서버, 데이터베이스가 받을 수 있는 요청량을 제한해서 요청을 받고 발급까지 하나의 트랜잭션에서 진행하는 방법이 있을 수 있습니다. 이를 위해서 흔히사용되는것은(유명 가수 콘서트 예매 등과같은곳에서) 순서대기열이 있습니다. 순서를 발급해준 후 순서가 됐을때 요청을 받고 해당 로직을 수행합니다.2번 방법을 선택한다면 하나의 트랜잭션에서 수행할 수 있을것 같습니다.감사합니다.

테스트에서 트랜잭션 어노테이션 질문 있습니다.

최광섭님 안녕하세요.테스트케이스에서 롤백을 활용하지 않는 이유는 롤백하지 않아도 되기때문입니다.실무에서 데이터베이스까지 같이 테스트를 해보고자 할때는 테스트컨테이너 같은것을 활용하여 진행합니다.이는 실행시마다 데이터가 없는 상태로 생성이 되기때문에 별도로 사용하지 않아도 되기때문입니다.혹시 롤백을 사용해야 하는 이유가 있다면 어떤 이유때문인지 알 수 있을까요?

강사님 강의를 듣고 실제 프로젝트에서 이벤트 응모 시스템을 만들어 봤습니다.

감바스님 안녕하세요.먼저 제 강의를 듣고 실제 프로젝트를 개발하고 잘 끝내셨다니 뿌듯합니다.아래와 같은 질문을 할 수 있을것같아요.redis 가 아키텍쳐에서 중요한 요소를 차지하고 있는듯한데 어느정도까지의 요청을 허용하나요?허용치를 넘게 된다면 지연이 발생하거나 redis 에 이슈가 생길 수 있을것같은데 이때는 어떻게 할 수 있을까요?쿠폰발급정보를 redis 에 저장하고 추후 스케쥴러로 DB 에 적재하는 방식을 선택했는데 이 사이에 redis 가 다운되어 발급정보가 날아갈 수 있을것같아요. 이 문제에 대해선 어떻게 해결하셨는지? redis 의 TTL 을 적용하셨는데 동작원리가 어떻게되는지? (내부 구현이 어떻게 되어있는지)당첨자조회 요청API 가 몰리게 되면 캐싱이 되어있지 않은 상태에서는 DB 에 조회요청이 갑자기 늘어날 수 있을것같습니다. 이것에 대해선 어떻게 처리하셨는지?동일한 사용자가 1번 당첨조회를 하고난 이후에는 다시 조회할 일이 적을것같은데 캐시의 의미가 있는지? 나아가 캐시히트율은 어떻게 되는지?블로그글을 2번정도 읽어보고 이정도의 질문이 생각났으며 답변까지 제가 말씀드리기는 힘들것 같습니다.꼬리질문은 감바스님의 답변에따라 방향성과 깊이가 달라지기때문에 어떤 꼬리질문이 나올지는 예측하기가 힘들것 같습니다.감사합니다.강의와 관련된 질문이 생기신다면 언제든 질문 부탁드릴게용 😄

optimistic Lock 재시도 질문입니다.

nova020510 님 안녕하세요.실무에서는 여러가지 방법중 적절한 방법을 선택합니다.따라서, 정답이 없으며 상황마다 다르다고 말씀드릴수밖에 없을것 같습니다.다만, 말씀하신대로 일정시간 대기후 무한히 실행하면 언제 빠져나올지 모르는 문제가 있으므로 n번의 재시도 이후에도 락을 얻지 못한다면 Exception 을 발생시키는 전략을 많이 사용하는 편입니다.감사합니다.

낙관적 락 테스트 실패

냥덕님 안녕하세요. 첨부해주신 코드는 트랜잭션과 재시도를 하는 부분이 같이 있습니다.강의 예제에서는 트랜잭션(서비스)에서는 데이터를 조작하는 부분만 있고, 재시도하는 부분은 facade 에 존재합니다. @Transactional public void increaseViewCountOpticLock(final long boardId) throws InterruptedException { while (true) { try { Board board = boardRepository.findByIdWithOptimistLock(boardId); board.increaseView(); // 조회수 증가 boardRepository.save(board); // 저장 break; // 성공 시 루프 탈출 } catch (ObjectOptimisticLockingFailureException e) { log.info("========================="); Thread.sleep(50); } } }트랜잭션이 열린이후로는 오류가 발생한 후 재시도를 할때 같은 데이터를 읽어오기때문에 트랜잭션 종료후 재시도를 해야합니다.감사합니다.

ApplyService 의 총 처리 시간이 궁금합니다.

조기윤님 안녕하세요.Thread 1 에서 10:00 에서 10:02 동안 incr coupon_count 메서드가 동작한다고 했을 때 10:02분에 끝나고나서 thread 2의 incr coupon_count 가 동작한다고 말씀하셨는데요이는 딱 redis 가 싱글스레드로 동작하는 시간 만큼만이 lock 이 걸린 시간이라고 보면 될까요?여기서 lock 은 어떤 lock 을 말씀하시는걸까요?강의에서 말하고자 했던것은 redis 는 순차적으로 명령을 실행하며 현재 실행중인 명령이 끝나야 다음 명령이 실행된다 였습니다!예컨데 ApplyService 의 apply 가 싱글 스레드, 단일 요청에 딱 2분이 걸리는 메서드라고 가정하고 그 안에 있는 couponCountRepository.increment() 가 1초가 걸린다고 가정하면 100개의 요청이 동시에 들어온 경우, 전체 요청이 모두 처리되는 시간이 2분 + 1*100초 = 3분 40초가 걸린다고 계산하는게 맞는거죠? 2분*100이 아니라요ApplyService.apply 메소드가 싱글스레드로 동작하며 메소드의 실행시간이 2분이라고 가정하고couponCountRepository.increment() 가 1초가 걸린다고 가정한다면100개의 요청을 처리하는데 걸리는 시간은 2분 * 100 일것같네요.ApplyService.apply 는 1번에 1개의 요청밖에 처리를 하지 못합니다. couponCountRepository.increment() 하는 로직은 ApplyService.apply 메소드 안에 존재합니다.ApplyService.apply 는 처리하는데 2분이 걸립니다. 싱글스레드 이므로 이전 요청이 끝나고난 이후 다음 요청을 처리할 수 있습니다. 따라서 100개의 요청을 처리하는데는 2 * 100 분이 걸릴것같네요

오류?

alpacaive 님 안녕하세요.히카리 설정이 무언가 안되있는듯해보입니다.강의실습을 하는데 문제가 없다면 일단은 넘어가도 될것같고, 문제가 있어서 진행이 되지않는다면 해당 소스를 깃에 올려주신 후, 사용하고 계시는 mysql 버전을 말씀해주신다면 봐보도록 하겠습니다!

쿠폰 생성 에러 처리에 관해서 질문이 있습니다.

홍혁준님 안녕하세요.해당건은 정책에 따라 다를것 같으며 구현방법은 여러가지가 있을것 같습니다.말씀해주신대로 try catch 와 같은것을 사용하여 실패시 redis 에 있는값을 줄이는 방법이 있을수 있을것 같습니다.다른 방법으로는 발송에 실패한 유저들을 따로 저장해두었다가 쿠폰발급을 해줄수도 있을것 같습니다.감사합니다.