Open MinJunKweon opened 2 years ago
null
이 되면 기본값인 라운드 로빈(Round-Robin) 알고리즘을 사용해 파티션들로 랜덤 전송된다.옵션명 | 설명 | 기본값 |
---|---|---|
buffer.memory | 카프카로 전송하기 위해 담아두는 버퍼 메모리 모든 파티션의 레코드의 크기를 다 더한 값을 계산함 ※ 서버로 전달될 수 있는 것보다 빠르게 보낸다면, 프로듀서는 max.block.ms 초(기본값 1분)까지 기다렸다가 가용 공간이 없으면 TimeoutException을 발생시킨다 |
32MB |
batch.size | 배치 전송을 위한 메시지들을 묶는 단위를 설정하는 배치 크기 각 파티션의 배치 전송용 버퍼 메모리만 계산함 이 값만큼 메시지가 모이면 데이터를 한번에 전송함 |
16KB |
linger.ms | 버퍼 메모리에서 대기하는 메시지들의 최대 대기시간 버퍼에 데이터가 많이 쌓이지 않았더라도 이 값만큼 시간이 지나면 무조건 브로커로 데이터를 전송함 |
0 (배치전송 사용X) |
compression.type | 프로듀서에 의해 생성되는 모든 데이터에 대한 압축 종류 gzip, snappy, lz4, zstd를 쓸 수 있다 |
none |
compression.type
을 설정하면 좀 더 적은 메모리로 효율적인 버퍼 메모리를 사용할 수 있다.snapshot
확장자 파일에 저장됨옵션명 | 설명 | 기본값 |
---|---|---|
enable.idempotence | 프로듀서가 중복 없는 전송을 허용할지 결정하는 옵션 true로 설정되어야 아래 설정 값들을 사용할 수 있다. |
true |
max.in.flight.requests.per.connection | ACK를 받지 않은 상태에서 하나의 커넥션에서 보낼 수 있는 최대 요청 수 | 5 |
acks | all , -1 : ISR 전체에 대해 ack를 대기하는 옵션0 : 메시지 전송후 ACK를 대기하지 않는 옵션1 : 리더 브로커에만 ACK를 기다리는 옵션 |
all |
retries | ACK를 받지 못한 경우 재시도하는 횟수 | 0 |
__transaction_state
에 저장함__transaction_state
토픽의 Partition 수와 Replication factor는 브로커 설정을 통해 관리자가 설정할 수 있음
transaction.state.log.num.partitions
(기본값 : 50)transaction.state.log.replication.factor
(기본값 : 3)__transaction_state
토픽을 트랜잭션 로그라고 불림peter-transaction-01::TransactionMetadata(transationalId=peter-transaction-01, producerId=48000, producerEpoch=0, txnTimeoutMs=60000, state=Empty, pendingState=None, topicPartitions=Set(), txnStartTimestamp=-1, txnLastUpdateTimestamp=1604742193026)
peter-transaction-01::TransactionMetadata(transationalId=peter-transaction-01, producerId=48000, producerEpoch=0, txnTimeoutMs=60000, state=Ongoing, pendingState=None, topicPartitions=Set(peter-test05-0), txnStartTimestamp=-1, txnLastUpdateTimestamp=1604742193106)
peter-transaction-01::TransactionMetadata(transationalId=peter-transaction-01, producerId=48000, producerEpoch=0, txnTimeoutMs=60000, state=PrepareCommit, pendingState=None, topicPartitions=Set(peter-test05-0), txnStartTimestamp=1604742193106, txnLastUpdateTimestamp=1604742193195)
peter-transaction-01::TransactionMetadata(transationalId=peter-transaction-01, producerId=48000, producerEpoch=0, txnTimeoutMs=60000, state=Empty, pendingState=CompleteCommit, topicPartitions=Set(), txnStartTimestamp=1604742193106, txnLastUpdateTimestamp=1604742193204)
옵션명 | 설명 | 기본값 |
---|---|---|
enable.idempotence | 프로듀서가 중복 없는 전송을 허용할지 결정하는 옵션 true로 설정되어야 아래 설정 값들을 사용할 수 있다. |
true |
max.in.flight.requests.per.connection | ACK를 받지 않은 상태에서 하나의 커넥션에서 보낼 수 있는 최대 요청 수 | 5 |
acks | all , -1 : ISR 전체에 대해 ack를 대기하는 옵션0 : 메시지 전송후 ACK를 대기하지 않는 옵션1 : 리더 브로커에만 ACK를 기다리는 옵션 |
all |
retries | ACK를 받지 못한 경우 재시도하는 횟수 | 0 |
transactional.id | 프로듀서 프로세스마다 설정하는 고유한 아이디 트랜잭션을 구분하기 위한 프로듀서 아이디 (ex. peter-transaction-01) |
null |
kafka-client
코드 상에서 Producer
인터페이스에 정의된 트랜잭션 메소드를 쓸 수 있음initTransactions()
메소드로 트랜잭션을 초기화beginTransaction()
메소드로 트랜잭션 시작을 명시abortTransaction()
메소드로 트랜잭션을 중단하도록 명시commitTransaction()
메소드로 트랜잭션을 커밋FindCoordinatorRequest
전송하여 트랜잭션 코디네이터의 위치를 찾음
transactional.id
)를 매핑하고 트랜잭션 전체를 관리함__trasnaction_state
토픽의 파티션 번호는 TID를 기반으로 해시하여 결정됨initTransactions()
메소드가 호출될 때, InitPidRequest
를 트랜잭션 코디네이터로 보냄. 이 때, TID도 함께 전송함
__transaction_state
트랜잭션 로그에 기록beginTransaction()
메소드를 사용해 새로운 트랜잭션의 시작을 알림
현재상태 : Ongoing
으로 표시)commitTransaction()
혹은 abortTransaction()
중 반드시 1개를 호출해야함
PrepareCommit
혹은 PrepareAbort
를 기록함PrepareCommit
이나 PrepareAbort
에 대해서 파티션에 트랜잭션을 커밋이 되었음을 알림 (컨트롤 메시지)
read_committed
설정을 쓰는 컨슈머들은 커밋된 메시지들만 읽을 수 있음정리는 다른 분들이 잘 해주셔서 저는 추가로 학습한 내용만 적겠습니다~~
순서가 그다지 중요하지 않은 경우라면 스티키 파티셔닝 전략을 적용하기를 권장합니다
프로듀서의 TRANSACTIONAL_ID_CONFIG 옵션은 실행하는 프로듀서 프로세스마다 고유한 아이디로 설정해야 합니다
여러 프로세스에서 같게 설정하면?
<transactionIdPrefix>.<group.id>.<topic>.<partition>
enable.idempotence
기본 값은 true
라고 합니당
isolation.level
의 default 값은 read_uncommitted
라고 합니다https://kafka.apache.org/documentation/#producerconfigs_enable.idempotence
@LOG-INFO 책이 잘못됐어용 버전업 되면서 3.2.0 버전부터 바뀌었답니당
참고 : https://kafka.apache.org/documentation/#upgrade_320_notable
@MinJunKweon 저도 다시 찾아보니까 3.0.0부터 적용을 하려 했는데 버그가 있어서 사용자가 설정값에 명시해줘야 했고, 버그 패치로 3.0.1, 3.1.1, 3.2.x 부터 기본 적용 되었다고 하네용
책은 2.x 버전 기준이라 false라고 한 듯..!
Q. __transaction_state
토픽에 트랜잭션 로그 상태가 1분간 업데이트 안되면 실패로 간주한다고 하는데, 메시지 프로듀싱 될 때마다 타이머가 리셋되는지?
Q. 트랜잭션 abort 되었을 때, 토픽에 프로듀싱 되었던 메시지들은 삭제되는가?
Q. 압축 전송이 효율이 좋다면서 왜 default로 사용하지 않을까?
A. 스터디에서 나온 이유 3가지로 정리
정리
파티셔너
프로듀서의 배치
중복 없는 전송
at-least-once
와most-once
, 그리고exactly-once
총 세 가지 방식을 사용한다.at-least-once
most-once
exactly-once
카프카의 트랜잭션