일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Helm
- k8s
- kafka-connect
- Elk
- Golang
- broker
- tls disable
- ElasticSearch
- partition
- 쿠버네티스
- http
- Produce
- Message
- kafka broker
- create topic
- kibana
- elastic
- Kubernetes
- Kafka
- topic
- command
- es
- consumer group
- Consumer
- loadbalance
- eck
- offset
- Kafka Connect
- minikube
- Producer
- Today
- Total
개발자의 개발괴발
[kafka] topic message 확인하기 본문
이전 글에서 topic에 메세지를 produce 해보았다.
topic에 저장된 message에 대해 살펴보자
토픽을 조회해보자.
$ kafka-topics.sh --list --bootstrap-server=localhost:9092
__consumer_offsets
myTopic
__consumer_offsets와 myTopic 두개의 토픽이 보인다.
__consumer_offsets 토픽은 자동으로 생성된 토픽이다.
우리가 생성한 myTopic에 저장된 내용을 보자.
kafka console consumer를 통해 내용을 확인해보면 아래와 같다.
$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic myTopic --from-beginning
Welcome
to
the
Confluent
Kafka
Golang
client
Welcome
to
the
Confluent
Kafka
Golang
client
Welcome
이전 글에서 "Welcome", "to", "the", "Confluent", "Kafka", "Golang", "client"라는 message를 입력했었다.
두번 반복된 이유는 내가 테스트 하면서 두번 넣어서 그렇다.(Welcome이 세번 있는 이유는 Welcome을 전송하고 네트워크가 끊어졌다.)
topic의 offset을 보자.
$ kafka-get-offsets.sh --bootstrap-server localhost:9092 --topic myTopic
myTopic:0:0
myTopic:1:0
myTopic:10:0
myTopic:11:0
myTopic:12:0
myTopic:13:0
myTopic:14:0
myTopic:15:7
myTopic:16:0
myTopic:17:0
myTopic:18:0
myTopic:19:0
myTopic:2:0
myTopic:3:0
myTopic:4:0
myTopic:5:0
myTopic:6:0
myTopic:7:7
myTopic:8:0
myTopic:9:1
myTopic 다음에 숫자는 partition number이고 그 다음 숫자는 message offset이다.
message가 들어있는 수와 같다고 생각할 수 있으나 다를 수 있다. 이유는 시간이 지나면 message가 삭제될 수 있기 때문이다. 이때 메세지는 삭제되어도 offset은 변하지 않는다.
내가 테스트하는동안 총 세번의 produce를 실행을 했다. 보통 생각 같으면 파티션에 고르게 분포가 될 것이라 생각했지만 하나의 배치는 같은 파티션에 저장되는 느낌이다.
아래처럼 각 파티션별로 데이터를 출력해보면 하나의 배치씩 나오는걸 볼 수 있다.(producer가 기본적으로 sticky uniform sticky partitioner를 사용해서 그렇다.)
I have no name!@bitnami-kafka-controller-0:/$ kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic myTopic --from-beginning --partition 15
Welcome
to
the
Confluent
Kafka
Golang
client
^CProcessed a total of 7 messages
I have no name!@bitnami-kafka-controller-0:/$ kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic myTopic --from-beginning --partition 7
Welcome
to
the
Confluent
Kafka
Golang
client
^CProcessed a total of 7 messages
I have no name!@bitnami-kafka-controller-0:/$ kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic myTopic --from-beginning --partition 9
Welcome
^CProcessed a total of 1 messages
이렇게 동작하는 이유 중 하나는 라운드 로빈으로 순서대로 보내게 되면 네트워크 비용이 많이 들게된다.
위 처럼 7개의 메세지를 라운드 로빈으로 보내려면 3개의 메세지는 0번 브로커, 2개는 1번 브로커 2개는 2번 브로커로 총 세개의 배치가 들어가게 된다. 그렇게 되면 네트워크를 더 사용하게 되고 CPU 또한 메세지를 나누는데 더 사용하게 된다.
자세한 내용은 KIP-794를 확인할 수 있다.
'개발 > kafka' 카테고리의 다른 글
[kafka] consumer group 소개 (0) | 2025.03.08 |
---|---|
[kafka] message consume하기 (0) | 2025.03.06 |
[kafka] message produce하기 (0) | 2025.03.03 |
[T.S] local에서 k8s의 broker에 접속이 안될때 2 (0) | 2025.03.03 |
[kafka] topic 만들기(with go) (0) | 2025.03.03 |