리뷰
Kafak 순서 전략은 어떻게 하는지?
파티션이 분산되더라도 발행한 날짜가 있을텐데, 타임 스탬프 기준으로 순서를 기준으로 하면 되지 않을까?
병렬 소비자는 컨슈머가 인스턴스가 한 대 일경우임, 일반적인 경우에는 파티션 하나에 컨슈머 하나임
병렬 소비자는 적용할 만 함, 대신에 처음에는 바로 하는 것 보다는 서버를 나누고 시작
- 나누는 이유는 서버를 분리 안하면 DB로 처리하는게 훨 빠른데 구지 kafka를 사용 할 필요가 없음
- 인스턴스를 나눠야함
- publisher server
- broker server
- consumer server
- 그 다음 병렬 소비자 적용
- cosumer group
- 그룹 단위로 하면 여러개를 붙힐수가 있다.
버저닝을 타임 스탬프로 하는게 어떤가? 실무에서도 이렇게 사용함
동시성을 제어해야하는 부분이 행사 조회 / 좌석 조회 / 결제 3부분인데 Kafka를 쓰게 되면 행사 조회 요청이 들어오면 처리하고 다시 producer가 메시지를 생성해서 좌석 조회로 보내고 다시 생성하고 반복하면서 처리해야 하는 걸까요?
- 결제 했을 때는 후처리 할 때 카프카 사용 현재, 질문은 카프카랑 별개임
- 그 전에는 조회 부분에는 락 없이 결제 할 때 락이 생기고, 오류가 발생을 해야함
저번에 JPA 질문에 대한 답변이 이해가 안가서 다시 질문드립니다.
- 티켓을 보면 연관관계로 키를 받는데, 복합키를 사용해서 써야되는지 아니면 쓰지 않고 사용해도되는지?
- 이 부분이 티켓을 생성(구매)할 때 연관관계를 맺어 그 엔티티의 값을 가져와서 생성하는게 맞는지?
- 예를 들어 event 엔티티의 행사이름이 필요하다면, event.getName()을 해서 저장하는게 맞는지, 그렇게 된다면, 여러 엔티티를 참조하고 있는 ticket 엔티티는 결국 각 특정값을 가져오기 위해 조회해서 찾게 되는데, 생성을 위해 조회쿼리가 네번 발생하는게 맞는지
- 티켓 데이터를 기준으로 유저, 이벤트, 타임.. 가지고 와야하는 상황이면은 현재가 맞음
- 유저 세부 정보가 더 필요한가?? 복합키 상관이 없다.
- 티켓을 생성하는데 유저 정보를 아이디를 가져와서 넣어주는게 맞긴한데, 꼼수가 필요하다.
- 효율을 위해 user_id에 컬럼을 생성해주면 된다.
Kafka에서 Consumer와 Partition의 개수가 중요한데 성능을 예측을 하고 진행하나요?
- 보통은 못한다. 만들어져있는 토픽의 파티션 개수를 늘리는 방식으로
- 컨슈머를 파티션의 개수를 맞춘다 보통 2개에서 3개
- 파티션 개수를 3~4개를 만들고 쿼리를 하는 형태 필요하면 2~4개 사이정도 늘리는 방식
- 구지 그렇게 까지 안해도 된다.
Kafka 멱등성 프로듀서를 사용 할 때 장애가 발생하지 않을 경우 확실한 보장을 하는데 장애 발생 시에는 따로 예외 처리를 해주는 방향으로 가나요 ?
- kafka dead letter를 사용해서 예외처리를 한다.
- 컨슈머 retry랑 같이 붙혀서 사용 한다고 한다.
- https://www.baeldung.com/kafka-spring-dead-letter-queue