Apache Kafka (9) 썸네일형 리스트형 카프카와 파일 시스템 보호되어 있는 글입니다. Fluss: Columnar Streaming Storage for StreamHouse 보호되어 있는 글입니다. Apache Kafka의 성능이 빠른 이유 보호되어 있는 글입니다. KStream, KTable, GlobalKTable 보호되어 있는 글입니다. Kafka Streams in Time Semantic 보호되어 있는 글입니다. Confluent Schema Registry에 curl로 접속하기 정확히는, 현재 Confluent Schema Registry에 등록된 스키마들을 request하는 command이지만, SR과의 connection이 있는지. API KEY와 Secret이 유효한지를 파악하는데 쓰일 수 있는 듯하다 curl --silent -X GET -u {SR_API_KEY:SR_API_SECRET} {SCHEMA_REGISTRY_URL}/schemas Apache Kafka의 성능: append-only and zero copy 아파치 카프카는 어떻게 대량의 데이터를 효율적으로 전송할까 카프카의 내부 아키텍처 동작 방식을 살펴보면 2가지 포인트가 존재한다 1. sequentail I/O 카프카는 append-only 방식으로 파일의 맨 끝에다 immutable한 새 record를 추가한다 카프카는 append만 가능한 순차적인 자료구조인 log를 기본 아키텍처로 사용하고 있다. 디스크에 random access 방식으로 data retrieve하는 것이 아닌, sequential 하게 데이터를 저장하여, conumser가 해당 record의 immutable한 offset 번호를 따라 데이터를 읽고 주기적으로 commit하여 어디까지 읽었는지 기록한다 2. zero-copy 만약 zero copy를 사용하지 않는다면 , 2번의 .. Idempotent Producer Udemy 강의를 들으며, 카프카 produce Acks에 대해 정리한 글이다 내용 정리 중 O'RELLY의 카프카 핵심 가이드에 수록된 내용도 참고를 하였다 Producer는 네트워크 에러 등의 이유로 동일한 메세지가 복사되어 두번 전송되는 일이 발생하곤 한다 본디 Producer에서 메세지를 전송하고, kafka broker가 메세지를 commit했다는 사실을 acknowledge 할 수 있어야 하나, 네트워크의 이유로 ack가 Producer에게 도달하지 못한다면 Producer는 메세지를 retry하게 된다 그러나 broker의 입장에서는 이미 한번 commit한 데이터와 동일한 메세지를 중복해서 commit하게 된다 문제는 Producer의 입장에서는 메세지는 단 한번만 전송이 된 것으로 간주한.. 이전 1 2 다음
