메시지 브로커 이해. ActiveMQ 및 Kafka를 사용한 메시징 메커니즘을 학습합니다. 제3장 카프카

작은 책의 번역 계속:
메시지 브로커 이해
저자: Jakub Korab, 발행인: O'Reilly Media, Inc., 발행일: 2017년 9781492049296월, ISBN: XNUMX.

이전 번역 부분: 메시지 브로커 이해. ActiveMQ 및 Kafka를 사용한 메시징 메커니즘을 학습합니다. 1 장 소개

제 3 장

카프카

Kafka는 기존 메시지 브로커의 일부 제한 사항을 해결하고 다양한 지점 간 상호 작용을 위해 여러 메시지 브로커를 설정하지 않아도 되도록 LinkedIn에서 개발되었습니다. 사용 사례 LinkedIn은 페이지 클릭 및 액세스 로그와 같은 매우 많은 양의 데이터를 단방향 수집에 크게 의존하면서 생산자나 다른 소비자의 생산성에 영향을 미치지 않고 여러 시스템에서 해당 데이터를 사용할 수 있도록 허용했습니다. 실제로 Kafka가 존재하는 이유는 Universal Data Pipeline이 설명하는 일종의 메시징 아키텍처를 얻기 위해서입니다.

이러한 궁극적인 목표를 고려할 때 자연스럽게 다른 요구 사항이 생겼습니다. Kafka는 다음을 수행해야 합니다.

• 매우 빠르게
• 메시지 작업 시 더 많은 대역폭 제공
• Publisher-Subscriber 및 Point-to-Point 모델 지원
• 소비자 추가로 속도를 늦추지 마십시오. 예를 들어 ActiveMQ에서 대기열과 주제의 성능은 대상의 소비자 수가 증가함에 따라 저하됩니다.
• 수평적으로 확장 가능해야 합니다. 메시지를 지속하는 하나의 브로커가 최대 디스크 속도에서만 그렇게 할 수 있다면 성능을 향상시키기 위해 단일 브로커 인스턴스를 넘어서는 것이 합리적입니다.
• 메시지 저장 및 재검색에 대한 액세스 제한

이 모든 것을 달성하기 위해 Kafka는 클라이언트와 메시징 브로커의 역할과 책임을 재정의하는 아키텍처를 채택했습니다. JMS 모델은 매우 브로커 지향적이며 브로커는 메시지 배포를 담당하고 클라이언트는 메시지 송수신에 대해서만 걱정하면 됩니다. 반면 Kafka는 클라이언트 중심적이며 클라이언트는 매우 빠르고 확장 가능한 브로커와 교환하여 관련 메시지를 소비자에게 공정하게 배포하는 것과 같은 전통적인 브로커의 많은 기능을 수행합니다. 전통적인 메시징 시스템으로 작업한 사람들에게 Kafka로 작업하려면 근본적인 생각의 변화가 필요합니다.
이러한 엔지니어링 방향으로 인해 기존 브로커에 비해 처리량을 훨씬 더 높일 수 있는 메시징 인프라가 만들어졌습니다. 앞으로 살펴보겠지만 이 접근 방식에는 장단점이 있습니다. 즉, Kafka는 특정 유형의 워크로드 및 설치된 소프트웨어에 적합하지 않습니다.

통합 대상 모델

위에서 설명한 요구 사항을 충족하기 위해 Kafka는 게시-가입 및 지점 간 메시징을 한 종류의 대상으로 결합했습니다. 주제. 이는 "주제"라는 단어가 (주제에서) 읽기가 지속되지 않는 브로드캐스트 메커니즘을 나타내는 메시징 시스템으로 작업한 사람들에게 혼란스럽습니다. Kafka 토픽은 이 책의 소개에 정의된 대로 하이브리드 대상 유형으로 간주되어야 합니다.

이 장의 나머지 부분에서는 달리 명시적으로 언급하지 않는 한 "주제"라는 용어는 Kafka 주제를 나타냅니다.

토픽이 동작하는 방식과 토픽이 제공하는 보장을 완전히 이해하려면 먼저 토픽이 Kafka에서 어떻게 구현되는지 살펴봐야 합니다.
Kafka의 각 주제에는 자체 로그가 있습니다.
Kafka에 메시지를 보내는 생산자는 이 로그에 쓰고 소비자는 지속적으로 앞으로 이동하는 포인터를 사용하여 로그에서 읽습니다. 주기적으로 Kafka는 해당 부분의 메시지를 읽었는지 여부에 관계없이 로그의 가장 오래된 부분을 삭제합니다. Kafka 설계의 핵심 부분은 브로커가 메시지를 읽든 읽지 않든 상관하지 않는다는 것입니다. 이는 클라이언트의 책임입니다.

"로그" 및 "포인터"라는 용어는 카프카 문서. 여기에서는 이해를 돕기 위해 이러한 잘 알려진 용어를 사용합니다.

이 모델은 모든 대기열의 메시지가 동일한 로그에 저장되고 브로커가 메시지를 읽은 후 삭제된 것으로 표시하는 ActiveMQ와 완전히 다릅니다.
이제 조금 더 깊이 들어가 주제 로그를 자세히 살펴보겠습니다.
Kafka 로그는 여러 파티션(그림 3-1). Kafka는 각 파티션에서 엄격한 순서를 보장합니다. 이것은 특정 순서로 파티션에 기록된 메시지가 동일한 순서로 읽혀진다는 것을 의미합니다. 각 파티션은 다음을 포함하는 롤링 로그 파일로 구현됩니다. 부분 집합 (하위 집합) 생성자가 주제로 보낸 모든 메시지의 생성된 주제에는 기본적으로 하나의 파티션이 포함됩니다. 파티션의 아이디어는 수평 확장을 위한 Kafka의 핵심 아이디어입니다.

그림 3-1. 카프카 파티션

생산자가 Kafka 주제에 메시지를 보낼 때 메시지를 보낼 파티션을 결정합니다. 이에 대해서는 나중에 자세히 살펴보겠습니다.

메시지 읽기

메시지를 읽으려는 클라이언트는 명명된 포인터를 관리합니다. 소비자 그룹, 이는 다음을 가리킨다. 오프셋 파티션의 메시지. 오프셋은 파티션 시작 시 0에서 시작하는 증분 위치입니다. 사용자 정의 group_id를 통해 API에서 참조되는 이 소비자 그룹은 다음에 해당합니다. 하나의 논리적 소비자 또는 시스템.

대부분의 메시징 시스템은 메시지를 병렬로 처리하기 위해 여러 인스턴스와 스레드를 사용하여 대상에서 데이터를 읽습니다. 따라서 일반적으로 동일한 소비자 그룹을 공유하는 많은 소비자 인스턴스가 있습니다.

읽기 문제는 다음과 같이 나타낼 수 있습니다.

• 주제에 여러 파티션이 있음
• 여러 소비자 그룹이 동시에 주제를 사용할 수 있습니다.
• 소비자 그룹은 여러 개의 개별 인스턴스를 가질 수 있습니다.

이것은 사소하지 않은 다대다 문제입니다. Kafka가 소비자 그룹, 소비자 인스턴스 및 파티션 간의 관계를 처리하는 방법을 이해하기 위해 점진적으로 더 복잡한 일련의 읽기 시나리오를 살펴보겠습니다.

소비자 및 소비자 그룹

하나의 파티션(그림 3-2).

그림 3-2. 소비자가 파티션에서 읽음

소비자 인스턴스가 자체 group_id를 사용하여 이 주제에 연결하면 읽기 파티션과 해당 파티션의 오프셋이 할당됩니다. 이 오프셋의 위치는 클라이언트에서 가장 최근 위치(최신 메시지) 또는 가장 초기 위치(가장 오래된 메시지)에 대한 포인터로 구성됩니다. 소비자는 주제에서 메시지를 요청(폴링)하여 로그에서 순차적으로 읽습니다.
오프셋 위치는 정기적으로 Kafka에 다시 커밋되고 내부 주제에 메시지로 저장됩니다. _소비자_오프셋. 일반 브로커와 달리 읽은 메시지는 여전히 삭제되지 않으며 클라이언트는 오프셋을 되감아 이미 본 메시지를 다시 처리할 수 있습니다.

두 번째 논리적 소비자가 다른 group_id를 사용하여 연결할 때 첫 번째(그림 3-3). 따라서 Kafka 토픽은 하나의 소비자가 있는 대기열과 같은 역할을 하고 여러 소비자가 구독하는 일반 게시-구독(pub-sub) 토픽처럼 작동하며 모든 메시지가 저장되고 여러 번 처리될 수 있다는 추가 이점이 있습니다.

그림 3-3. 서로 다른 소비자 그룹의 두 소비자가 동일한 파티션에서 읽습니다.

소비자 그룹의 소비자

하나의 소비자 인스턴스가 파티션에서 데이터를 읽을 때 포인터를 완전히 제어하고 이전 섹션에서 설명한 대로 메시지를 처리합니다.
소비자의 여러 인스턴스가 하나의 파티션이 있는 주제에 동일한 group_id로 연결된 경우 마지막으로 연결된 인스턴스에 포인터에 대한 제어권이 부여되고 그 순간부터 모든 메시지를 수신합니다(그림 3-4).

그림 3-4. 동일한 소비자 그룹의 두 소비자가 동일한 파티션에서 읽습니다.

소비자 인스턴스 수가 파티션 수를 초과하는 이러한 처리 방식은 일종의 독점 소비자로 생각할 수 있습니다. 이는 소비자 인스턴스의 "활성-수동"(또는 "hot-warm") 클러스터링이 필요한 경우 유용할 수 있지만 병렬로 여러 소비자를 실행("active-active" 또는 "hot-hot")하는 것이 훨씬 더 일반적입니다. 대기 중입니다.

위에서 설명한 이 메시지 배포 동작은 일반 JMS 대기열의 동작 방식과 비교할 때 놀라운 것일 수 있습니다. 이 모델에서 대기열로 전송된 메시지는 두 소비자 사이에 균등하게 분배됩니다.

대부분의 경우 소비자의 여러 인스턴스를 만들 때 메시지를 병렬로 처리하거나 읽기 속도를 높이거나 읽기 프로세스의 안정성을 높이기 위해 이 작업을 수행합니다. 한 번에 하나의 소비자 인스턴스만 파티션에서 데이터를 읽을 수 있으므로 Kafka에서는 어떻게 이를 달성합니까?

이를 수행하는 한 가지 방법은 단일 소비자 인스턴스를 사용하여 모든 메시지를 읽고 스레드 풀에 전달하는 것입니다. 이 접근 방식은 처리 처리량을 증가시키지만 소비자 로직의 복잡성을 증가시키고 판독 시스템의 견고성을 증가시키는 데 아무런 도움이 되지 않습니다. 정전 또는 유사한 이벤트로 인해 소비자 사본 하나가 다운되면 빼기가 중지됩니다.

Kafka에서 이 문제를 해결하는 정식 방법은 b를 사용하는 것입니다.О더 많은 파티션.

파티셔닝

파티션은 단일 브로커 인스턴스의 대역폭을 넘어 주제 읽기 및 확장을 병렬화하는 주요 메커니즘입니다. 이를 더 잘 이해하기 위해 두 개의 파티션이 있는 주제가 있고 한 명의 소비자가 이 주제를 구독하는 상황을 가정해 보겠습니다(그림 3-5).

그림 3-5. 한 소비자가 여러 파티션에서 읽음

이 시나리오에서 소비자는 두 파티션의 group_id에 해당하는 포인터에 대한 제어권을 부여받고 두 파티션에서 메시지를 읽기 시작합니다.
동일한 group_id에 대한 추가 소비자가 이 주제에 추가되면 Kafka는 파티션 중 하나를 첫 번째 소비자에서 두 번째 소비자로 재할당합니다. 그런 다음 소비자의 각 인스턴스는 주제의 한 파티션에서 읽습니다(그림 3-6).

메시지가 20개의 스레드에서 병렬로 처리되도록 하려면 최소 20개의 파티션이 필요합니다. 파티션 수가 적으면 배타적 소비자에 대한 논의에서 앞서 설명한 것처럼 작업할 것이 없는 소비자만 남게 됩니다.

그림 3-6. 동일한 소비자 그룹의 두 소비자가 서로 다른 파티션에서 읽습니다.

이 체계는 JMS 대기열을 유지하는 데 필요한 메시지 배포에 비해 Kafka 브로커의 복잡성을 크게 줄입니다. 여기서 다음 사항에 대해 걱정할 필요가 없습니다.

• 라운드 로빈 할당, 프리페치 버퍼의 현재 용량 또는 이전 메시지(JMS 메시지 그룹의 경우)를 기반으로 다음 메시지를 수신해야 하는 소비자.
• 어떤 메시지가 어떤 소비자에게 전송되고 실패 시 다시 전달되어야 하는지 여부.

Kafka 브로커가 해야 할 일은 소비자가 메시지를 요청할 때 소비자에게 순차적으로 메시지를 전달하는 것입니다.

그러나 교정 및 실패한 메시지 재전송에 대한 요구 사항은 사라지지 않습니다. 이에 대한 책임은 단순히 브로커에서 클라이언트로 전달됩니다. 즉, 코드에서 이를 고려해야 합니다.

메시지 보내기

메시지를 보낼 파티션을 결정하는 것은 해당 메시지 생성자의 책임입니다. 이 작업이 수행되는 메커니즘을 이해하려면 먼저 실제로 정확히 무엇을 보내는지 고려해야 합니다.

JMS에서는 메타데이터(헤더 및 속성)와 페이로드(페이로드)를 포함하는 본문이 있는 메시지 구조를 사용하는 반면 Kafka에서는 메시지가 다음과 같습니다. 쌍 "키-값". 메시지 페이로드는 값으로 전송됩니다. 반면에 키는 주로 파티셔닝에 사용되며 다음을 포함해야 합니다. 비즈니스 로직 특정 키관련 메시지를 동일한 파티션에 넣습니다.

2장에서는 관련 이벤트를 단일 소비자가 순서대로 처리해야 하는 온라인 베팅 시나리오에 대해 논의했습니다.

1. 사용자 계정이 구성되었습니다.
2. 돈이 계정에 적립됩니다.
3. 계좌에서 돈을 인출하는 내기가 이루어집니다.

각 이벤트가 주제에 게시된 메시지인 경우 자연 키는 계정 ID입니다.
메시지가 Kafka Producer API를 사용하여 전송되면 메시지와 Kafka 클러스터의 현재 상태가 주어지면 메시지를 전송해야 하는 파티션의 ID를 반환하는 파티션 함수로 메시지가 전달됩니다. 이 기능은 Partitioner 인터페이스를 통해 Java로 구현됩니다.

이 인터페이스는 다음과 같습니다.

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

Partitioner 구현은 키에 대해 기본 범용 해싱 알고리즘을 사용하여 파티션을 결정하거나 키가 지정되지 않은 경우 라운드 로빈을 사용합니다. 이 기본값은 대부분의 경우 잘 작동합니다. 그러나 앞으로는 직접 작성하고 싶을 것입니다.

나만의 파티셔닝 전략 작성

메시지 페이로드와 함께 메타데이터를 보내려는 예를 살펴보겠습니다. 예제의 페이로드는 게임 계정에 입금하라는 지시입니다. 명령은 전송 시 수정되지 않도록 보장하고 신뢰할 수 있는 업스트림 시스템만 해당 명령을 시작할 수 있도록 보장하려는 것입니다. 이 경우 송신 및 수신 시스템은 서명을 사용하여 메시지를 인증하는 데 동의합니다.
일반 JMS에서는 단순히 "메시지 서명" 속성을 정의하고 메시지에 추가합니다. 그러나 Kafka는 메타데이터를 전달하는 메커니즘을 제공하지 않고 키와 값만 제공합니다.

값은 무결성을 유지하려는 은행 송금 페이로드이므로 키에서 사용할 데이터 구조를 정의할 수밖에 없습니다. 파티셔닝을 위해 계정 ID가 필요하다고 가정하면 계정과 관련된 모든 메시지를 순서대로 처리해야 하므로 다음과 같은 JSON 구조가 나옵니다.

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

서명 값은 페이로드에 따라 달라지므로 Partitioner 인터페이스의 기본 해싱 전략은 관련 메시지를 안정적으로 그룹화하지 않습니다. 따라서 이 키를 구문 분석하고 accountId 값을 분할하는 자체 전략을 작성해야 합니다.

Kafka에는 저장소의 메시지 손상을 감지하는 체크섬이 포함되어 있으며 전체 보안 기능 세트가 있습니다. 그럼에도 불구하고 위와 같은 산업별 요구 사항이 때때로 나타납니다.

사용자의 분할 전략은 모든 관련 메시지가 동일한 분할에서 끝나도록 해야 합니다. 이것은 간단해 보이지만 관련 메시지 순서 지정의 중요성과 주제의 파티션 수가 얼마나 고정되어 있는지에 따라 요구 사항이 복잡해질 수 있습니다.

주제의 파티션 수는 트래픽이 초기 예상을 초과하는 경우 추가될 수 있으므로 시간이 지남에 따라 변경될 수 있습니다. 따라서 메시지 키는 원래 전송된 파티션과 연결될 수 있으며, 이는 생산자 인스턴스 간에 공유할 상태의 일부를 의미합니다.

고려해야 할 또 다른 요소는 파티션 간에 메시지를 균등하게 분배하는 것입니다. 일반적으로 키는 메시지 전체에 균등하게 배포되지 않으며 해시 함수는 작은 키 집합에 대한 메시지의 공정한 배포를 보장하지 않습니다.
메시지 분할을 선택하더라도 구분자 자체를 재사용해야 할 수 있습니다.

서로 다른 지리적 위치에 있는 Kafka 클러스터 간에 데이터를 복제하기 위한 요구 사항을 고려하십시오. 이를 위해 Kafka는 한 클러스터에서 메시지를 읽고 다른 클러스터로 전송하는 데 사용되는 MirrorMaker라는 명령줄 도구와 함께 제공됩니다.

MirrorMaker는 클러스터 간에 복제할 때 메시지 간의 상대적 순서를 유지하기 위해 복제된 주제의 키를 이해해야 합니다. 해당 주제에 대한 파티션 수가 두 클러스터에서 동일하지 않을 수 있기 때문입니다.

기본 해싱 또는 라운드 로빈이 대부분의 시나리오에서 잘 작동하므로 사용자 지정 파티셔닝 전략은 상대적으로 드뭅니다. 그러나 강력한 순서 보장이 필요하거나 페이로드에서 메타데이터를 추출해야 하는 경우 파티셔닝을 자세히 살펴봐야 합니다.

Kafka의 확장성과 성능 이점은 기존 브로커의 일부 책임을 클라이언트로 이전하는 데서 비롯됩니다. 이 경우 병렬로 작업하는 여러 소비자에게 잠재적으로 관련된 메시지를 배포하기로 결정합니다.

JMS 브로커도 이러한 요구 사항을 처리해야 합니다. 흥미롭게도 JMS 메시지 그룹(SLB(스티키 로드 밸런싱) 전략의 변형)을 통해 구현된 동일한 소비자에게 관련 메시지를 보내는 메커니즘도 발신자가 메시지를 관련으로 표시해야 합니다. JMS의 경우 브로커는 이 관련 메시지 그룹을 여러 소비자 중 하나의 소비자에게 보내고 소비자가 떨어지면 그룹의 소유권을 이전하는 역할을 담당합니다.

생산자 계약

분할은 메시지를 보낼 때 고려해야 할 유일한 사항이 아닙니다. Java API에서 Producer 클래스의 send() 메서드를 살펴보겠습니다.

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

두 메서드 모두 전송 작업이 즉시 수행되지 않음을 나타내는 Future를 반환한다는 점에 즉시 유의해야 합니다. 그 결과 메시지(ProducerRecord)가 각 활성 파티션의 전송 버퍼에 기록되고 Kafka 클라이언트 라이브러리의 백그라운드 스레드로 브로커에 전송됩니다. 이렇게 하면 속도가 엄청나게 빨라지지만 경험이 없는 응용 프로그램은 프로세스가 중지되면 메시지를 잃을 수 있습니다.

항상 그렇듯이 전송 작업을 보다 안정적으로 수행할 수 있는 방법이 있습니다. 이 버퍼의 크기는 0으로 설정할 수 있으며 보내는 응용 프로그램 스레드는 다음과 같이 브로커로의 메시지 전송이 완료될 때까지 강제로 대기합니다.

RecordMetadata metadata = producer.send(record).get();

메시지 읽기에 대해 자세히 알아보기

메시지 읽기에는 추측해야 할 추가적인 복잡성이 있습니다. 메시지에 대한 응답으로 메시지 수신기를 실행할 수 있는 JMS API와 달리 소비자 Kafka는 투표만 합니다. 방법을 자세히 살펴 보겠습니다. 투표()이 목적으로 사용:

ConsumerRecords < K, V > poll(long timeout);

메서드의 반환 값은 여러 개체를 포함하는 컨테이너 구조입니다. 소비자 기록 잠재적으로 여러 파티션에서. 소비자 기록 파생된 파티션과 같은 관련 메타데이터가 있는 키-값 쌍에 대한 홀더 개체 자체입니다.

2장에서 논의한 바와 같이, 예를 들어 클라이언트가 메시지를 처리할 수 없거나 중단된 경우와 같이 성공적으로 또는 성공적으로 처리되지 않은 경우 메시지에 어떤 일이 발생하는지 염두에 두어야 합니다. JMS에서 이것은 확인 모드를 통해 처리되었습니다. 브로커는 성공적으로 처리된 메시지를 삭제하거나 원시 또는 가짜 메시지를 다시 전달합니다(트랜잭션이 사용되었다고 가정).
Kafka는 매우 다르게 작동합니다. 교정 후 메시지는 브로커에서 삭제되지 않으며 실패 시 발생하는 문제는 교정 코드 자체의 책임입니다.

우리가 말했듯이 소비자 그룹은 로그의 오프셋과 연결됩니다. 이 오프셋과 관련된 로그 위치는 다음에 대한 응답으로 발행될 다음 메시지에 해당합니다. 투표(). 이 오프셋이 증가하는 시점이 판독에 결정적입니다.

앞에서 설명한 읽기 모델로 돌아가서 메시지 처리는 세 단계로 구성됩니다.

1. 읽을 메시지를 검색합니다.
2. 메시지를 처리합니다.
3. 메시지를 확인합니다.

Kafka 소비자는 구성 옵션과 함께 제공됩니다. 활성화.자동.커밋. 이것은 자주 사용되는 기본 설정이며 "자동"이라는 단어가 포함된 설정에서 흔히 볼 수 있습니다.

Kafka 0.10 이전에는 이 옵션을 사용하는 클라이언트가 다음 호출에서 읽은 마지막 메시지의 오프셋을 보냅니다. 투표() 처리 후. 이는 클라이언트가 이미 메시지를 처리했지만 호출하기 전에 예기치 않게 파괴된 경우 이미 가져온 메시지를 다시 처리할 수 있음을 의미했습니다. 투표(). 브로커는 메시지를 읽은 횟수에 대한 상태를 유지하지 않기 때문에 해당 메시지를 검색하는 다음 소비자는 문제가 발생했음을 알 수 없습니다. 이 동작은 의사 트랜잭션이었습니다. 오프셋은 메시지가 성공적으로 처리된 경우에만 커밋되지만 클라이언트가 중단되면 브로커는 동일한 메시지를 다른 클라이언트에 다시 보냅니다. 이 동작은 메시지 전달 보장 "적어도 한 번".

Kafka 0.10에서는 구성된 대로 클라이언트 라이브러리에서 주기적으로 커밋이 트리거되도록 클라이언트 코드가 변경되었습니다. auto.commit.interval.ms. 이 동작은 JMS AUTO_ACKNOWLEDGE와 DUPS_OK_ACKNOWLEDGE 모드 사이에 있습니다. 자동 커밋을 사용하면 메시지가 실제로 처리되었는지 여부에 관계없이 메시지가 커밋될 수 있습니다. 이는 느린 소비자의 경우에 발생할 수 있습니다. 소비자가 중단된 경우 커밋된 위치에서 시작하여 다음 소비자가 메시지를 가져오므로 메시지가 누락될 수 있습니다. 이 경우 Kafka는 메시지를 손실하지 않았으며 읽기 코드는 메시지를 처리하지 않았습니다.

이 모드는 버전 0.9와 동일한 약속을 가지고 있습니다. 메시지를 처리할 수 있지만 실패할 경우 오프셋이 커밋되지 않아 잠재적으로 배달이 두 배가 될 수 있습니다. 실행할 때 가져오는 메시지가 많을수록 투표(), 이 문제가 많을수록.

21페이지의 "대기열에서 메시지 읽기"에서 설명한 것처럼 장애 모드를 고려할 때 메시징 시스템에서 메시지를 한 번만 전달하는 것은 없습니다.

Kafka에는 오프셋(offset)을 커밋(commit)하는 두 가지 방법이 있습니다: 자동 및 수동. 두 경우 모두 메시지가 처리되었지만 커밋 전에 실패한 경우 메시지를 여러 번 처리할 수 있습니다. 커밋이 백그라운드에서 발생하고 처리되기 전에 코드가 완료된 경우 메시지를 전혀 처리하지 않도록 선택할 수도 있습니다(아마도 Kafka 0.9 및 이전 버전에서).

매개변수를 설정하여 Kafka 소비자 API에서 수동 오프셋 커밋 프로세스를 제어할 수 있습니다. 활성화.자동.커밋 다음 메서드 중 하나를 false로 지정하고 명시적으로 호출합니다.

void commitSync();
void commitAsync();

"적어도 한 번" 메시지를 처리하려면 다음을 사용하여 오프셋을 수동으로 커밋해야 합니다. commitSync()메시지를 처리한 후 즉시 이 명령을 실행합니다.

이러한 방법은 메시지가 처리되기 전에 승인되는 것을 허용하지 않지만 트랜잭션인 것처럼 보이게 하면서 잠재적인 처리 지연을 제거하는 데 아무 것도 하지 않습니다. Kafka에는 트랜잭션이 없습니다. 클라이언트는 다음을 수행할 수 없습니다.

• 가짜 메시지를 자동으로 롤백합니다. 소비자는 메시지를 재전달하기 위해 브로커에 의존할 수 없기 때문에 문제가 있는 페이로드 및 백엔드 중단으로 인해 발생하는 예외를 직접 처리해야 합니다.
• 하나의 원자적 작업으로 여러 주제에 메시지를 보냅니다. 곧 보게 되겠지만, 전송될 때 트랜잭션을 조정하지 않는 Kafka 클러스터의 다른 시스템에 다양한 주제 및 파티션에 대한 제어가 상주할 수 있습니다. 이 글을 쓰는 시점에 KIP-98로 이를 가능하게 하기 위한 몇 가지 작업이 수행되었습니다.
• 한 주제에서 한 메시지를 읽는 것과 다른 메시지를 다른 주제로 보내는 것을 연관시키십시오. 다시 말하지만 Kafka의 아키텍처는 하나의 버스로 실행되는 많은 독립 머신에 의존하며 이를 숨기려는 시도는 없습니다. 예를 들어 링크를 허용하는 API 구성 요소가 없습니다. 소비자 и 프로듀서 거래에서. JMS에서 이것은 객체에 의해 제공됩니다. 세션생성되는 것 메시지 생산자 и 메시지 소비자.

트랜잭션에 의존할 수 없다면 기존 메시징 시스템에서 제공하는 것과 유사한 의미 체계를 어떻게 제공할 수 있습니까?

소비자 충돌과 같이 메시지가 처리되기 전에 소비자의 오프셋이 증가할 가능성이 있는 경우 소비자는 파티션이 할당될 때 소비자 그룹이 메시지를 놓쳤는지 여부를 알 수 있는 방법이 없습니다. 따라서 한 가지 전략은 오프셋을 이전 위치로 되감는 것입니다. Kafka 소비자 API는 이를 위해 다음 메서드를 제공합니다.

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

방법 구하다() 방법과 함께 사용할 수 있습니다
offsetsForTimes(지도 timestampsToSearch) 과거의 특정 시점으로 되감기.

암묵적으로 이 접근 방식을 사용하면 이전에 처리된 일부 메시지를 다시 읽고 처리할 가능성이 매우 높습니다. 이를 방지하기 위해 4장에서 설명한 대로 멱등성 읽기를 사용하여 이전에 본 메시지를 추적하고 중복을 제거할 수 있습니다.

또는 메시지 손실이나 중복이 허용되는 한 소비자 코드를 단순하게 유지할 수 있습니다. 로그 이벤트, 메트릭, 클릭 추적 등과 같이 Kafka가 일반적으로 사용되는 사용 사례를 고려할 때 개별 메시지의 손실이 주변 애플리케이션에 큰 영향을 미치지 않을 것임을 이해합니다. 이러한 경우 기본값은 완벽하게 허용됩니다. 반면에 애플리케이션에서 지불을 보내야 하는 경우 각 개별 메시지를 신중하게 처리해야 합니다. 그것은 모두 맥락에 달려 있습니다.

개인적인 관찰에 따르면 메시지의 강도가 증가함에 따라 각 개별 메시지의 가치는 감소합니다. 큰 메시지는 집계된 형식으로 볼 때 가치가 있는 경향이 있습니다.

고가용성

고가용성에 대한 Kafka의 접근 방식은 ActiveMQ의 접근 방식과 매우 다릅니다. Kafka는 모든 브로커 인스턴스가 동시에 메시지를 수신하고 배포하는 스케일 아웃 클러스터를 중심으로 설계되었습니다.

Kafka 클러스터는 서로 다른 서버에서 실행되는 여러 브로커 인스턴스로 구성됩니다. Kafka는 각 노드에 전용 스토리지가 있는 일반 독립형 하드웨어에서 실행되도록 설계되었습니다. SAN(Network Attached Storage) 사용은 여러 컴퓨팅 노드가 시간을 놓고 경쟁할 수 있으므로 권장되지 않습니다.Ы전자 저장 간격 및 충돌을 만듭니다.

카프카는 항상 켜져 체계. 많은 대규모 Kafka 사용자는 클러스터를 종료하지 않으며 소프트웨어는 항상 순차적으로 다시 시작하여 업데이트됩니다. 이는 브로커 간의 메시지 및 상호 작용에 대해 이전 버전과의 호환성을 보장함으로써 달성됩니다.

서버 클러스터에 연결된 브로커 주 키퍼, 구성 데이터 레지스트리 역할을 하며 각 브로커의 역할을 조정하는 데 사용됩니다. ZooKeeper 자체는 정보의 복제를 통해 고가용성을 제공하는 분산 시스템입니다. 정족수.

기본 사례에서 주제는 다음 속성을 사용하여 Kafka 클러스터에 생성됩니다.

• 파티션 수. 앞서 논의한 바와 같이 여기에서 사용되는 정확한 값은 원하는 병렬 판독 수준에 따라 다릅니다.
• 복제 팩터(팩터)는 클러스터에서 이 파티션에 대한 로그를 포함해야 하는 브로커 인스턴스 수를 결정합니다.

조정을 위해 ZooKeepers를 사용하여 Kafka는 클러스터의 브로커 간에 새 파티션을 공정하게 분배하려고 시도합니다. 이것은 컨트롤러 역할을 하는 단일 인스턴스에 의해 수행됩니다.

런타임에 각 주제 파티션에 대해 제어 장치 브로커에게 역할 할당 리더 (리더, 마스터, 발표자) 및 추종자 (추종자, 노예, 부하). 이 파티션의 리더 역할을 하는 브로커는 생산자가 보낸 모든 메시지를 수신하고 소비자에게 메시지를 배포하는 역할을 합니다. 메시지가 주제 파티션으로 전송되면 해당 파티션의 팔로워 역할을 하는 모든 브로커 노드에 메시지가 복제됩니다. 파티션에 대한 로그를 포함하는 각 노드를 호출합니다. 레플리카. 브로커는 일부 파티션에서는 리더 역할을 하고 다른 파티션에서는 팔로워 역할을 할 수 있습니다.

리더가 보유한 모든 메시지를 포함하는 팔로워를 호출합니다. 동기화된 복제본 (동기화된 상태의 복제본, 동기화된 복제본). 파티션의 리더 역할을 하는 브로커가 작동 중지되면 해당 파티션에 대해 최신 상태이거나 동기화된 브로커가 리더 역할을 맡을 수 있습니다. 믿을 수 없을 정도로 지속 가능한 디자인입니다.

생산자 구성의 일부는 매개변수입니다. Acks, 애플리케이션 스레드가 계속 전송하기 전에 메시지 수신을 확인(확인)해야 하는 복제본의 수를 결정합니다(0, 1 또는 모두). 로 설정한 경우 모든그런 다음 메시지가 수신되면 리더는 주제 설정에 의해 정의된 여러 큐(자체 포함)에서 레코드의 확인(확인)을 수신하는 즉시 확인을 생산자에게 다시 보냅니다. min.insync.replicas (기본값 1). 메시지를 성공적으로 복제할 수 없는 경우 생산자는 응용 프로그램 예외(충분하지 않은 복제본 또는 충분하지 않음복제본추가후).

일반적인 구성은 복제 계수가 3(파티션당 리더 1개, 팔로워 2개) 및 매개변수가 있는 주제를 생성합니다. min.insync.replicas 이 경우 2로 설정됩니다. 이 경우 클러스터는 주제 파티션을 관리하는 브로커 중 하나가 클라이언트 응용 프로그램에 영향을 주지 않고 중단되도록 허용합니다.

이는 성능과 안정성 간의 이미 익숙한 절충안으로 되돌아갑니다. 팔로워의 확인(확인)을 위한 추가 대기 시간을 희생하여 복제가 발생합니다. 그러나 병렬로 실행되기 때문에 최소 XNUMX개 노드에 대한 복제는 XNUMX개 노드와 동일한 성능을 갖습니다(네트워크 대역폭 사용량 증가는 무시).

이 복제 체계를 사용함으로써 Kafka는 작업을 통해 각 메시지를 디스크에 물리적으로 기록할 필요가 없습니다. 동조(). 생산자가 보낸 각 메시지는 분할 영역 로그에 기록되지만 2장에서 설명한 것처럼 파일 쓰기는 초기에 운영 체제의 버퍼에서 수행됩니다. 이 메시지가 다른 Kafka 인스턴스에 복제되고 메모리에 있는 경우 리더의 손실은 메시지 자체가 손실되었음을 의미하지 않으며 동기화된 복제본에 의해 인계될 수 있습니다.
작업 수행 거부 동조() Kafka는 메시지를 메모리에 쓸 수 있는 만큼 빠르게 메시지를 받을 수 있음을 의미합니다. 반대로 메모리를 디스크로 플러시하는 것을 방지할 수 있는 시간이 길수록 좋습니다. 이러한 이유로 Kafka 브로커에 64GB 이상의 메모리가 할당되는 것은 드문 일이 아닙니다. 이러한 메모리 사용량은 단일 Kafka 인스턴스가 기존 메시지 브로커보다 수천 배 빠른 속도로 쉽게 실행될 수 있음을 의미합니다.

작업을 적용하도록 Kafka를 구성할 수도 있습니다. 동조() 메시지 패키지에. Kafka의 모든 것이 패키지 지향적이기 때문에 실제로 많은 사용 사례에서 꽤 잘 작동하며 매우 강력한 보증이 필요한 사용자에게 유용한 도구입니다. Kafka의 순수한 성능의 대부분은 브로커에 패킷으로 전송되는 메시지와 이러한 메시지가 제로 카피 작업(한 메모리 영역에서 다른 메모리 영역으로 데이터를 복사하는 작업이 수행되지 않는 작업). 후자는 큰 성능 및 리소스 이득이며 파티션 구성표를 정의하는 기본 로그 데이터 구조를 사용해야만 가능합니다.

단일 Kafka 브로커를 사용하는 것보다 Kafka 클러스터에서 훨씬 더 나은 성능이 가능합니다. 주제 파티션이 여러 개별 시스템에 걸쳐 확장될 수 있기 때문입니다.

결과

이 장에서는 Kafka 아키텍처가 클라이언트와 브로커 간의 관계를 재구성하여 기존 메시지 브로커보다 처리량이 몇 배 더 많은 매우 강력한 메시징 파이프라인을 제공하는 방법을 살펴보았습니다. 이를 달성하기 위해 사용하는 기능에 대해 논의했으며 이 기능을 제공하는 애플리케이션의 아키텍처를 간략하게 살펴보았습니다. 다음 장에서는 메시징 기반 응용 프로그램이 해결해야 하는 일반적인 문제를 살펴보고 이를 처리하기 위한 전략을 논의합니다. 사용 사례에 대한 적합성을 평가할 수 있도록 일반적으로 메시징 기술에 대해 설명하는 방법을 간략하게 설명하는 것으로 이 장을 끝낼 것입니다.

이전 번역 부분: 메시지 브로커 이해. ActiveMQ 및 Kafka를 사용한 메시징 메커니즘을 학습합니다. 1장

번역 완료: tele.gg/middle_java

계속 될 ...

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

조직에서 Kafka를 사용하고 있습니까?

• Да

• 아니

• 이전에는 사용했지만 지금은 사용하지 않음

• 우리는 사용할 계획입니다

38명의 사용자가 투표했습니다. 8명의 사용자가 기권했습니다.

출처 : habr.com