Consumer Group메시지를 효율적으로 처리하기 위해 여러 개의 컨슈머(Consumer)를 묶어 관리하는 논리적인 단위 아래 예시 상황을 살펴보자.한 개의 Topic 안에 5개의 Partition이 존재하고 , 3개의 Consumer로 구성된 Consumer Group이 존재한다. 이때, 각각의 Consumer는 각각 다른 Partition에서 데이터를 읽게 된다. Consumer1은 Partition 0과 1, Consumer2는 Partition 2와 3 Consumer3는 Partition 4의 데이터를 각각 읽는다. 이렇게 같은 Consumer Group 안의 모든 Consumer는 읽기를 공유한다.⇒ 이와 같은 방식으로 그룹이 Kafka 토픽 전체를 읽게 된다. Consumer Group ..
ConsumerConsumer는 pull 모델을 구현해 토픽에서 데이터를 읽어 들인다.Kafka 브로커(서버)에 데이터를 요청하고 되돌아오는 응답을 받는다.데이터를 Consumer에게 pushing 하는 것은 Kafka 브로커가 아닌 Pull Model이다.파티션에서 데이터를 읽어야 하는 Consumer들은 자동으로 어떤 Kafka 브로커에서 읽을지 알게 된다.브로커에 오류가 발생해 동작하지 않더라도, Consumer는 복구할 방법을 알고 있다.모든 파티션에서 읽히는 데이터는 순서대로 읽히게 된다.낮은 오프셋 → 높은 오프셋각 파티션에서 0 → 1 → 2 → 3 → …하지만, 파티션을 읽는 순서는 보장되지 않는다.순서는 각각의 파티션 안에만 존재한다.Consumer DeserializerKafka로부터 ..
ProducerKafka 토픽과 파티션에 데이터를 작성 하는 주체⇒ 프로듀서는 자신이 어떤 파티션에 기록하는지 미리 알고 있다. 그리고 Kafka Broker(Kafka Server)가 그것을 갖게 된다.즉, 기록할 파티션을 미리 결정하는 것은 Kafka 서버가 아닌, 프로듀서이다.Message Key프로듀서는 메시지 안에 메시지 키를 가지고 있는데, 파티션을 구분할 때 사용된다.Key는 메시지 안에 포함되며 문자열, 숫자, 바이너리 … 등 다양한 형태가 될 수 있다.Key를 추가하는 것은 선택사항이다.데이터의 처리 순서와 밀접한 관련이 있다.특정 파티션에 메시지를 고정해, 해당 파티션 내에서 메시지가 순서대로 처리되도록 보장할 수 있다.Key가 NULL인 경우데이터가 RR(Round-Robin) 방식으..
TopicKafka topic은kafka 클러스터 안에 있는 데이터 스트림이다.kafka 클러스터에는 많은 토픽이 존재할 수 있다.원하는 건 모두 Kafka 토픽에 전송할 수 있다. ⇒ 모든 종류의 메시지 형식을 지원(e.g. JSON, Avro, Text, Binary …)Kafka 클러스터 안에서 이름을 이용해 토픽을 식별한다.토픽 안에 있는 메시지들의 순서 := 데이터 스트림예를 들어, DB에 테이블을 만들려고 한다면 Topic은 DB의 그 테이블과 비슷할 것이다. 하지만, 토픽을 쿼리할 수 없다. 대신 Kafka 토픽에 데이터를 추가할 수 있다.Kafka ProducerTopic에 데이터 추가Kafka ConsumerTopic에서 데이터 읽기 PartitionTopic은 파티션으로 분할할 수 있다..