Open MinJunKweon opened 2 years ago
sendOffsetsToTransaction()
메소드는 프로듀서의 메소드인데, 그러면 프로듀서가 컨슈밍까지 완료하는 것 아닌가?
partition.assignment.strategy
가 여러 개면 어떻게 동작하는지? 두 개를 같이 쓸 수 있는걸까요?__consumer_offsets
토픽에 저장됨__consumer_offsets
의 파티션 수, 리플리케이션 팩터는 server.properties
파일에서 변경 가능
offsets.topic.num.partitions
: 기본값 50offsets.topic.replication.factor
: 기본값 3bootstrap.brokers
리스트에 있는 브로커에게 컨슈머 클라이언트와 초기 커넥션을 연결하기 위한 요청을 보냄group.initial.rebalance.delay.ms
의 시간 동안 컨슈머의 요청을 대기컨슈머 옵션 | 설명 | 기본값 |
---|---|---|
heartbeat.interval.ms |
그룹 코디네이터와 하트비트 인터벌 시간 해당 시간은 session.timeout.ms보다 낮게 설정해야 함. 일반적으로 1/3 수준 |
3000 (3초) |
session.timeout.ms |
컨슈머와 브로커사이의 session timeout 시간 이 시간이 지나면 해당 컨슈머는 종료되거나 장애가 발생한 것으로 간주되어 리밸런싱이 일어남 |
10000 (10초) |
max.poll.interval.ms |
컨슈머 poll() 호출 인터벌 시간 컨슈머가 poll()을 호출 후 최대 설정시간만큼 지나도 다시 poll()을 호출하지 않으면 문제가 있는 것으로 판단 |
300000 (5분) |
group.instance.id
를 통해 스태틱 멤버십을 적용할 수 있음session.timeout.ms
를 재시작 하는 시간보다 길게 설정해야함
파티션 할당 전략 | 설명 |
---|---|
Range 파티션 할당 전략 | 토픽별로 할당 전략을 사용함. 동일한 키를 이용하는 2개 이상의 토픽을 컨슘할 때 유용함 (기본값) |
Round-Robin 파티션 할당 전략 | 사용 가능한 파티션과 컨슈머들을 라운드 로빈으로 할당함. |
Sticky 파티션 할당 전략 | 컨슈머가 컨슘하고 있는 파티션을 계속 유지할 수 있음 |
Cooperative Sticky 파티션 할당 전략 | 스티키 방식과 유사하지만, 전체 일시 정지가 아닌 연속적인 재조정 방식 (3.0 버전 이상 기본값) |
isolation.level
옵션에 read_committed
값을 주면 트랜잭션이 완료된 메시지만 읽을 수 있게 됨sendOffsetsToTransaction()
메소드를 사용하면 컨슈머 그룹의 오프셋까지 트랜잭션에 추가할 수 있음컨슈머 그룹
별 파티션 오프셋 정보는 __consumer_offsets
토픽에 저장된다
마지막까지 읽은 위치
가 아니라 다음으로 읽어야 할 위치
컨슈머 그룹
관리를 위해 그룹 코디네이터
가 존재함
컨슈머 그룹
: 1 그룹 코디네이터
컨슈머 그룹이 구독한 토픽의 파티션들
과 컨슈머 그룹의 멤버들
을 트래킹함컨슈머 리밸런싱
을 발생시킴컨슈머 그룹
에는 리더 컨슈머
가 존재
리더 컨슈머
가 됨파티션 할당 전략
에 따라 그룹 내 컨슈머들에게 파티션을 할당(assign)한 뒤 그룹 코디네이터
에게 전달partition.assignment.strategy
heartbeat.interval.ms
session.timeout.ms
max.poll.interval.ms
max.poll.records
)스태틱 멤버십
group.instance.id
를 부여하면 스태틱 멤버
로 지정됨컨슈머 리밸런싱
이 일어나지 않음session.timeout.ms
안에는 다시 실행되어야 함Exactly Once
컨트롤 메시지
)를 표시한 레코드만 읽는다면 정확히 한 번 읽을 수 있다isolation.level
: read_committed
poll()
)auto.commit.interval.ms
는 커밋 최소 시간일 뿐, 무조건 보장하지 않는다. 더 넘어갈 수 있다.Understanding Kafka partition assignment strategies and how to write your own custom assignor
위 문서를 보면 partition.assignment.strategy
가 list인 이유를 알 수 있네여.
컨슈머 그룹 내의 모든 컨슈머들이 같은 프로토콜을 지원한다는 보장이 없어서 여러 개 지정하는 듯
HTTP의 Accept 헤더 같은 느낌
worker thread 병렬처리(여러 파티션 consuming 병렬처리 말고) 중 늦은 메시지가 먼저 처리되면?
끄적끄적
공식문서를 살펴보니 3버전부터는 기본적으로 컨슈머 파티션 전략은 레인지와 협력적 스티키 두 개가 디폴트 설정으로 잡혀있다고 합니다. 디폴트는 레인지고, 레인지를 리스트에서 제거하면 협력적 스티키가 된다고 하네요. 공식 도큐먼트
exactly once는 트랜잭션 코디네이터와 통신하는 부분은 따로 없고, 트랜잭션이 완료된 메시지만 읽을 수 있다. 기본적으로 read_uncommitted이고 추후 read_committed로 옵션을 변경하면 트랜잭션이 완료된 메시지만 읽을 수 있다.
컨슈머 자체에는 트랜잭션을 보장하는 코디네이터와의 통신이 없으므로 컨슈머 자체만의 트랜잭션 처리로는 중복이 발생할 여지가 존재한다.
따라서
sendOffsetsToTransaction
메소드를 이용해, 컨슈머 그룹의 오프셋 커밋을 트랜잭션에 포함시켜서, 컨슈머-메시지 처리-프로듀싱 동작이 모두 하나의 트랜잭션으로 동작하게 되야한다.