Kafka는 뛰어난 분산 메시지 미들웨어입니다. Kafka는 메시지 통신을 위해 많은 시스템에서 사용됩니다. 분산 메시징 시스템을 이해하고 사용하는 것은 백엔드 개발자에게 거의 필요한 기술이 되었습니다. 오늘은 码哥字节 일반적인 Kafka 면접 질문부터 시작해서 Kafka에 대해 이야기해보겠습니다.
분산 메시징은 RPC, HTTP, RMI 등과 달리 분산 중간 에이전트를 사용하여 통신하는 메커니즘입니다. 그림에서 볼 수 있듯이, 업스트림 비즈니스 시스템은 메시지 미들웨어를 사용한 후 메시지를 보내고, 메시지는 먼저 메시지 미들웨어에 저장되며, 메시지 미들웨어는 해당 메시지를 해당 비즈니스 모듈 애플리케이션에 배포합니다(분산 생산자-소비자 모델). 이 비동기식 접근 방식은 서비스 간의 결합을 줄입니다.
메시지 미들웨어 정의:
시스템 아키텍처에서 추가 구성 요소를 참조하면 필연적으로 시스템의 아키텍처 복잡성이 증가하고 운영 및 유지 관리가 어려워집니다. 그렇다면 시스템에서 분산 메시징 미들웨어를 사용하면 어떤 이점이 있을까요? 시스템에서 메시지 미들웨어의 역할은 무엇입니까? ㅋㅋㅋ 주문 보장
Kafka 아키텍처의 일반 개념:
Kafka Topic 파티션 레이아웃
Kafka 파티션 Topic, 파티션을 동시에 읽고 쓸 수 있습니다.
Kafka 소비자 오프셋
카프카의 아키텍처에 대해 간단히 이야기해볼까요?
Producer, Consumer, Consumer Group, Topic, Partition
Kafka 푸시 모드인가요, 풀 모드인가요?
Kafka Producer는 Push 모드를 사용하여 Broker에 메시지를 보내고 Consumer는 Pull 모드를 사용하여 소비합니다. 풀 모드를 사용하면 소비자가 오프셋을 스스로 관리할 수 있어 읽기 성능을 제공할 수 있습니다
Kafka는 어떻게 메시지를 브로드캐스트하나요?
소비자 단체
카프카의 메시지는 순서대로 되어 있나요?
주제 수준은 순서가 없고 파티션은 순서가 있습니다.
Kafka는 읽기-쓰기 분리를 지원합니까?
지원되지 않으며 Leader만이 외부 읽기 및 쓰기 서비스를 제공합니다.
Kafka는 어떻게 높은 데이터 가용성을 보장합니까?
Copy, ack, HW
카프카에서 사육사의 역할은?
클러스터 관리, 메타데이터 관리
트랜잭션을 지원하나요?
0.11 이후에는 트랜잭션이 지원되며 "정확히 한 번" 달성할 수 있습니다
파티션 수를 줄일 수 있나요?
아니요, 데이터가 손실됩니다
Kafka의 명령줄 도구는 Kafka 패키지의 /bin 디렉터리에 있으며, 주로 서비스 및 클러스터 관리 스크립트, 구성 스크립트, 정보 보기 스크립트, 주제 스크립트, 클라이언트 스크립트 등이 포함되어 있습니다. .
대개 kafka-console-consumer.sh和kafka-console-producer.sh脚本来测试 Kafka 生产和消费，kafka-consumer-groups.sh可以查看和管理集群中的 Topic，kafka-topics.shKafka의 소비자 그룹 상태를 보는 데 사용됩니다.
Kafka 생산자의 일반적인 생산 로직에는 다음 단계가 포함됩니다.
Producer가 메시지를 보내는 과정은 아래 그림과 같으며 일괄적으로 Broker에 보내야 합니다. 拦截器，序列化器和分区器，最终由累加器
producer기본값: 200, 각 배치의 메시지 수, 비동기식에서만 작동합니다.
기본값: 0, 0은 생산자가 리더의 확인을 기다릴 필요가 없음을 의미하고, 1은 리더가 로컬 로그에 대한 쓰기를 확인하고 즉시 확인해야 함을 의미하며, -1은 생산자가 확인해야 함을 의미합니다. 모든 백업이 완료된 후. 이는 비동기 모드에서만 작동합니다. 이 매개변수의 조정은 데이터 손실과 전송 효율성 사이의 균형입니다. 데이터 손실에 민감하지 않지만 효율성을 고려하는 경우 0으로 설정하면 효율성이 크게 향상될 수 있습니다. 데이터를 보내는 생산자.
request.timeout.ms
기본값: 10000, 확인 시간 초과.
partitioner.class
기본값: kafka.producer.DefaultPartitioner, kafka.producer.Partitioner를 구현해야 하며 키를 기반으로 분할 전략을 제공합니다. 동일한 유형의 메시지를 순차적으로 처리해야 하는 경우가 있으므로 동일한 유형의 데이터를 동일한 파티션에 할당하도록 할당 전략을 사용자 정의해야 합니다.
producer.type
기본값: sync는 메시지가 동기적으로 전송되는지 또는 비동기적으로 전송되는지 여부를 지정합니다. 비동기 비동기 일괄 전송에는 kafka.producer.AyncProducer를 사용하고 동기 동기화에는 kafka.producer.SyncProducer를 사용합니다. 동기식 및 비동기식 전송은 메시지 생성 효율성에도 영향을 미칩니다.
compression.topic
기본값: 없음, 메시지 압축, 기본적으로 압축 안 함. 다른 압축 방법으로는 "gzip", "snappy" 및 "lz4"가 있습니다. 메시지를 압축하면 네트워크 전송량과 네트워크 IO가 크게 줄어들어 전반적인 성능이 향상됩니다.
compressed.topics
기본값: null 압축이 설정되면 특정 주제 압축을 지정할 수 있습니다. 지정하지 않으면 모든 압축이 수행됩니다.
message.send.max.retries
기본값: 3, 최대 메시지 전송 시도 횟수.
retry.backoff.ms
기본값: 300, 각 시도에 추가 간격이 추가됩니다.
topic.metadata.refresh.interval.ms
기본값: 600000, 정기적으로 메타데이터를 얻는 시간. 파티션이 손실되고 리더를 사용할 수 없는 경우 생산자는 메타데이터도 적극적으로 얻습니다. 0인 경우 메시지가 전송될 때마다 메타데이터를 얻습니다. 이는 권장되지 않습니다. 음수인 경우 실패 시에만 메타데이터를 가져옵니다.
queue.buffering.max.ms
기본값: 5000, 생산자 대기열에서 데이터를 캐싱하는 최대 시간, asyc에만 해당.
queue.buffering.max.message
기본값: 10000, 생산자가 캐시하는 최대 메시지 수, 비동기식에만 해당됩니다.
queue.enqueue.timeout.ms
기본값: -1, 0은 대기열이 가득 차면 폐기되고, 음수 값은 대기열이 가득 차면 블록이고, 양수 값은 대기열이 가득 차면 해당 블록의 시간입니다. 비동기식의 경우에만 해당됩니다.
Kafka에는 소비자 그룹이라는 개념이 있습니다. 각 소비자는 할당된 파티션의 메시지만 사용할 수 있으며, 각 파티션은 소비자 그룹에서 한 명의 소비자만 사용할 수 있습니다. 따라서 동일한 소비자 그룹의 소비자 수가 파티션 수를 초과하는 경우 일부 소비자에게는 사용할 수 없는 파티션이 할당됩니다. 소비자 그룹과 소비자 간의 관계는 아래 그림에 나와 있습니다.
Kafka Consumer 클라이언트가 메시지를 소비하는 단계는 일반적으로 다음 단계로 구성됩니다.
Kafka의 소비자 클라이언트는 스레드로부터 안전하기 때문입니다. 스레드를 보장하기 위해 소비 성능 향상을 위해 Consumer 측에서 Reactor와 유사한 스레드 모델을 사용하여 데이터를 소비할 수 있습니다.
호스트:포트 형식. host：port 格式。key.serializer对应，key 的反序列化方式。value.serializer对应，value 的反序列化方式。false，则需要在程序中手动提交位移。对于精确到一次的语义，最好手动提交位移max.poll.recordskey.serializer는 키의 역직렬화 방법에 해당합니다. 🎜🎜🎜🎜value.deserializer: value.serializer는 value의 역직렬화 방법에 해당합니다. 🎜🎜🎜🎜session.timeout.ms: 코디네이터 감지에 실패한 시간입니다. 기본값은 10초입니다. 이 매개변수는 하트비트 만료 시간과 유사하게 소비자 그룹(comsummer, 그룹의 구성원) 충돌을 적극적으로 감지하는 시간 간격입니다. 🎜🎜🎜🎜auto.offset.reset: 이 속성은 소비자가 오프셋이 없고 오프셋이 유효하지 않은 파티션을 읽고 있음을 지정합니다(소비자의 현재 오프셋이 오랫동안 만료되어 만료되어 삭제되었습니다). 이 경우 어떻게 해야 합니까? 기본값은 최신입니다. 이는 최신 레코드(소비자가 시작된 후 생성된 레코드)에서 데이터를 읽는 것을 의미합니다. 이는 오프셋이 유효하지 않을 때 소비자가 또는 시작 위치부터 데이터 읽기를 시작합니다. 🎜🎜🎜🎜enable.auto.commit: false인 경우 프로그램에서 수동으로 변위를 제출해야 합니다. 정확한 한 번 의미 체계의 경우 변위를 수동으로 제출하는 것이 좋습니다. 🎜🎜🎜🎜fetch.max.bytes: 한 번에 가져온 데이터의 최대 바이트 수 🎜🎜🎜🎜max.poll.records: 반환된 최대 메시지 단일 폴 호출로 처리 논리가 매우 가벼운 경우 이 값을 적절하게 늘릴 수 있습니다. 그러나max.poll. 기록 데이터는 session.timeout.ms 내에서 처리되어야 합니다. 기본값은 500🎜🎜🎜🎜request.timeout.ms입니다: 요청 응답을 위한 최대 대기 시간입니다. 제한 시간 내에 응답이 수신되지 않으면 Kafka는 메시지를 다시 보내거나 재시도 횟수가 초과되면 직접 실패합니다.rebalance는 본질적으로 소비자 그룹 아래의 모든 소비자가 구독 주제의 각 파티션을 할당하기로 합의할 수 있는 방법을 규정하는 프로토콜입니다. 예를 들어, 특정 그룹에는 20명의 소비자가 있고 100개의 파티션이 있는 주제를 구독합니다. 일반적인 상황에서 Kafka는 각 소비자에게 평균 5개의 파티션을 할당합니다. 이 할당 프로세스를 재조정이라고 합니다.
언제 리밸런싱을 해야 할까요?
이것도 자주 언급되는 질문이에요. 재조정에는 세 가지 트리거 조건이 있습니다.
그룹 내에서 파티션을 할당하는 방법은 무엇인가요?
Kafka는 기본적으로 Range와 Round-Robin이라는 두 가지 할당 전략을 제공합니다. 물론 Kafka는 플러그형 할당 전략을 채택하고 사용자가 자신만의 할당자를 만들어 다양한 할당 전략을 구현할 수 있습니다.
/bin디렉토리, 카프카 클러스터 관리, 토픽 관리, 카프카 생산 및 소비
분산 데이터 시스템에서 파티션은 일반적으로 시스템의 처리 용량을 향상시키고 복제본을 통해 데이터의 고가용성을 보장하는 데 사용됩니다. 다중 분할은 이러한 여러 복사본 중에서 하나만이 리더이고 나머지는 팔로어 복사본인 것을 동시에 처리하는 기능을 의미합니다. 리더 카피만이 외부 세계에 서비스를 제공할 수 있습니다. 여러 팔로워 복사본은 일반적으로 리더 복사본과 다른 브로커에 저장됩니다. 이 메커니즘을 통해 시스템이 중단되면 다른 후속 복사본이 신속하게 "정상으로 전환"되어 외부 세계에 서비스 제공을 시작할 수 있습니다.
팔로워 카피는 왜 읽기 서비스를 제공하지 않나요?
이 문제는 본질적으로 성능과 일관성 사이의 균형입니다. 팔로어 카피가 외부 세계에도 서비스를 제공한다면 어떻게 될까요? 우선 성능이 확실히 좋아질 것이다. 그러나 동시에 일련의 문제가 발생할 것입니다. 데이터베이스 트랜잭션의 팬텀 읽기 및 더티 읽기와 유사합니다. 예를 들어 Kafka 주제 a에 데이터 조각을 쓰는 경우 소비자 b는 주제 a의 데이터를 소비하지만 소비자 b가 읽는 파티션 복사본에 최신 메시지가 기록되지 않았기 때문에 이를 소비할 수 없다는 것을 알게 됩니다. 이때 다른 Consumer c는 Leader Copy를 소비하기 때문에 최신 데이터를 소비할 수 있습니다. Kafka는 WH 및 오프셋 관리를 사용하여 소비자가 사용할 수 있는 데이터와 현재 기록되는 데이터를 결정합니다.
리더만이 외부 읽기 서비스를 제공할 수 있으므로 리더 선출 방법
kafka에서는 리더 레플리카와 동기화된 레플리카를 ISR 레플리카 세트에 넣습니다. 물론, 리더 사본은 항상 ISR 사본 세트에 존재합니다. 일부 특별한 경우에는 ISR 사본에 리더 사본이 하나만 있습니다. 리더가 실패하면 카카파는 사육사를 통해 이러한 상황을 감지하고, ISR 사본에서 새로운 사본을 선택하여 리더가 되어 외부 세계에 서비스를 제공한다. 그런데 여기에는 또 다른 문제가 있는데 앞서 언급한 것처럼 ISR 레플리카 세트에 리더만 있을 가능성이 있는데, 이때 리더 레플리카 세트가 비어 있게 됩니다. 이때 unclean.leader.election.enable 파라미터를 true로 설정하면 Kafka는 비동기식 리더가 될 레플리카, 즉 ISR 레플리카 세트에 없는 레플리카를 선택하게 된다.
사본이 있으면 사본 동기화 문제가 발생합니다
Kafka는 할당된 모든 복제본(AR)에서 사용 가능한 복제본 목록(ISR)을 유지 관리합니다. 생산자가 브로커에게 메시지를 보내면 ack配置来确定需要等待几个副本已经同步了消息才相应成功，Broker 内部会ReplicaManager 서비스를 기반으로 꽃과 리더 간의 데이터 동기화를 관리합니다.
한편으로는 서로 다른 파티션이 서로 다른 시스템에 위치할 수 있기 때문입니다. , 클러스터의 장점을 최대한 활용하고 기계 간 병렬 처리를 달성할 수 있습니다. 반면, 파티션은 물리적으로 하나의 폴더에 해당하므로 동일한 노드에 여러 개의 파티션이 있더라도 동일한 노드의 서로 다른 파티션을 서로 다른 디스크 드라이브에 배치하여 디스크 간 병렬 처리를 최대한 활용할 수 있습니다. 여러 디스크 중.
각 파티션 디렉터리의 Kafka 파일은 동일한 크기의 데이터 파일로 균등하게 절단됩니다(기본 파일 크기는 500MB이며 수동으로 설정할 수 있음). 각 데이터 파일을 세그먼트 파일이라고 하며 각 세그먼트는 추가를 사용하여 데이터를 추가합니다.
Kafka는 어떻게 고가용성을 보장하나요?
복제본을 사용하여 데이터의 고가용성, 생산자 승인, 재시도, 자동 리더 선택, 소비자 자체 균형을 보장합니다.
Kafka의 전달 의미는 무엇입니까?
배달 의미는 일반적으로
at least once、at most once和exactly once입니다. Kafka는 ack 구성을 통해 처음 두 개를 구현합니다.
Replic은 무엇을 하나요?
높은 데이터 가용성 달성
AR 및 ISR이란 무엇입니까?
AR: 할당된 복제본. AR은 토픽 생성 후 파티션 생성 시 할당되는 레플리카 집합이다. 레플리카 개수는 레플리카 인자에 따라 결정된다. ISR: 동기화 복제본. Kafka에서 특히 중요한 개념은 리더와 동기화되는 AR의 복제본 세트를 나타냅니다. AR의 복제본은 ISR에 없을 수도 있지만 Leader 복제본은 당연히 ISR에 포함됩니다. ISR과 관련하여 또 다른 일반적인 인터뷰 질문은 사본이 ISR에 속해야 하는지 여부를 결정하는 방법입니다. 현재 판단은 Follower Replica의 LEO가 Leader의 LEO보다 뒤처지는 시간이 Broker 측 매개변수인 Replica.lag.time.max.ms의 값을 초과하는지 여부에 따라 결정됩니다. 초과되면 복제본이 ISR에서 제거됩니다.
리더와 플라워는 무엇인가요?
Kafka에서 HW는 무엇을 의미하나요?
하이 워터마크. 이는 소비자가 읽을 수 있는 메시지의 범위를 제어하는 중요한 필드입니다. 일반 소비자는 리더 복제본의 로그 시작 오프셋과 HW(독점) 사이의 모든 메시지만 "볼" 수 있습니다. 수위 위의 메시지는 소비자에게 보이지 않습니다.
Kafka는 뛰어난 성능을 보장하기 위해 어떤 처리를 했나요?
파티션 동시성, 디스크 순차 읽기 및 쓰기, 페이지 캐시 압축, 고성능 직렬화(바이너리), 메모리 매핑 잠금 없는 오프셋 관리, Java NIO 모델
이 기사에서는 구현에 대해 다루지 않습니다. 그러나 Kafka는 실제로 훌륭한 오픈 소스 시스템입니다. 많은 우아한 아키텍처 디자인과 소스 코드 디자인은 배울 가치가 있습니다. 관심 있는 학생들이 이 오픈 소스 시스템에 대해 더 깊이 이해하는 것이 좋습니다. 건축 설계 능력, 코딩 능력, 성능 최적화가 큰 도움이 될 것입니다.
위 내용은 인터뷰 관점에서 완성된 Kafka의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
