카프카는 어떻게 현실이 되었나

헤이 하브르!

저는 자체 알림 센터를 개발하는 Tinkoff 팀에서 일하고 있습니다. 저는 주로 Spring boot를 사용하여 Java로 개발하고, 프로젝트에서 발생하는 다양한 기술적인 문제를 해결합니다.

대부분의 마이크로서비스는 메시지 브로커를 통해 비동기적으로 서로 통신합니다. 이전에는 IBM MQ를 브로커로 사용했는데, 이는 더 이상 로드에 대처할 수 없지만 동시에 높은 전달 보장을 제공했습니다.

대체품으로 확장 가능성이 높지만 안타깝게도 다양한 시나리오에 대한 구성에 대해 거의 개별적인 접근 방식이 필요한 Apache Kafka가 제공되었습니다. 또한 기본적으로 Kafka에서 작동하는 최소 한 번 전달 메커니즘은 기본적으로 필요한 수준의 일관성을 유지하는 것을 허용하지 않았습니다. 다음으로 Kafka 구성 경험을 공유하겠습니다. 특히 정확히 XNUMX회 전달을 구성하고 실행하는 방법을 알려 드리겠습니다.

배송 보장 등

아래에 설명된 설정은 기본 연결 설정과 관련된 여러 가지 문제를 방지하는 데 도움이 됩니다. 하지만 먼저 가능한 디버그를 용이하게 하는 한 가지 매개변수에 주목하고 싶습니다.

이것은 도움이 될 것입니다 클라이언트.ID 생산자와 소비자를 위한. 얼핏 보면 애플리케이션 이름을 값으로 사용할 수 있으며 대부분의 경우 이 방법이 작동합니다. 애플리케이션이 여러 소비자를 사용하고 동일한 client.id를 제공하는 상황에서는 다음과 같은 경고가 발생합니다.

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0

Kafka가 포함된 애플리케이션에서 JMX를 사용하려는 경우 이것이 문제가 될 수 있습니다. 이 경우 애플리케이션 이름과 주제 이름 등을 조합하여 client.id 값을 사용하는 것이 가장 좋습니다. 구성 결과는 명령 출력에서 ​​볼 수 있습니다. 카프카 소비자 그룹 Confluent의 유틸리티에서:

이제 보장된 메시지 전달에 대한 시나리오를 살펴보겠습니다. Kafka Producer에는 매개변수가 있습니다. Acks이를 통해 클러스터 리더가 성공적으로 작성된 메시지를 고려하는 데 필요한 승인 횟수를 구성할 수 있습니다. 이 매개변수는 다음 값을 사용할 수 있습니다.

• 0 - 승인이 고려되지 않습니다.
• 1이 기본 매개변수이며 확인하려면 복제본 1개만 필요합니다.
• −1 — 동기화된 모든 복제본의 승인이 필요합니다(클러스터 설정 min.insync.replicas).

나열된 값에서 -1과 같은 ack가 메시지가 손실되지 않을 것이라는 가장 강력한 보장을 제공한다는 것이 분명합니다.

우리 모두 알고 있듯이 분산 시스템은 신뢰할 수 없습니다. 일시적인 오류로부터 보호하기 위해 Kafka Producer는 다음 옵션을 제공합니다. 재시도, 재전송 시도 횟수를 설정할 수 있습니다. 배달.시간 초과.ms. retries 매개변수의 기본값은 Integer.MAX_VALUE(2147483647)이므로, Delivery.timeout.ms만 변경하여 메시지 재시도 횟수를 조정할 수 있습니다.

XNUMX회만 배송을 향해 나아가고 있습니다

나열된 설정을 통해 생산자는 높은 보증을 바탕으로 메시지를 전달할 수 있습니다. 이제 하나의 메시지 복사본만 Kafka 주제에 기록되도록 하는 방법에 대해 이야기해 보겠습니다. 가장 간단한 경우 이를 수행하려면 Producer에서 매개변수를 설정해야 합니다. 활성화.멱등성 사실로. 멱등성은 한 주제의 특정 파티션에 하나의 메시지만 기록되도록 보장합니다. 멱등성을 활성화하기 위한 전제 조건은 다음과 같습니다. acks = 모두, 재시도 > 0, max.in.flight.requests.per.connection ≤ 5. 개발자가 이러한 매개변수를 지정하지 않으면 위 값이 자동으로 설정됩니다.

멱등성이 구성되면 동일한 메시지가 매번 동일한 파티션에 있는지 확인해야 합니다. partitioner.class 키와 매개변수를 Producer로 설정하면 됩니다. 열쇠부터 시작해 보겠습니다. 각 제출마다 동일해야 합니다. 이는 원본 게시물의 비즈니스 ID를 사용하여 쉽게 달성할 수 있습니다. partitioner.class 매개변수의 기본값은 다음과 같습니다. 기본파티셔너. 이 분할 전략을 사용하면 기본적으로 다음과 같이 작동합니다.

• 메시지를 보낼 때 파티션이 명시적으로 지정되면 이를 사용합니다.
• 파티션을 지정하지 않고 키를 지정한 경우 키의 해시로 파티션을 선택합니다.
• 파티션과 키가 지정되지 않은 경우 파티션을 하나씩 선택합니다(라운드 로빈).

또한 키를 사용하고 매개변수를 사용하여 멱등성 전송을 수행합니다. max.in.flight.requests.per.connection = 1 소비자에 대한 간소화된 메시지 처리를 제공합니다. 또한 클러스터에 액세스 제어가 구성된 경우 주제에 멱등적으로 쓰기 위한 권한이 필요하다는 점을 기억할 가치가 있습니다.

갑자기 키를 통한 멱등성 전송 기능이 부족하거나 생산자 측 논리에서 여러 파티션 간의 데이터 일관성을 유지해야 하는 경우 트랜잭션이 도움이 됩니다. 또한 체인 트랜잭션을 사용하면 Kafka의 레코드를 데이터베이스의 레코드와 조건부로 동기화할 수 있습니다. 생산자로 트랜잭션 전송을 활성화하려면 멱등성이 있어야 하며 추가로 설정되어야 합니다. transactional.id. Kafka 클러스터에 액세스 제어가 구성되어 있는 경우 멱등성 레코드와 같은 트랜잭션 레코드에는 transactional.id에 저장된 값을 사용하여 마스크로 부여할 수 있는 쓰기 권한이 필요합니다.

공식적으로는 애플리케이션 이름과 같은 모든 문자열을 트랜잭션 식별자로 사용할 수 있습니다. 그러나 동일한 transactional.id를 사용하여 동일한 애플리케이션의 여러 인스턴스를 시작하면 Kafka가 이를 좀비 프로세스로 간주하므로 처음 시작된 인스턴스가 오류와 함께 중지됩니다.

org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.

이 문제를 해결하기 위해 환경 변수에서 얻은 호스트 이름 형식으로 애플리케이션 이름에 접미사를 추가합니다.

생산자는 구성되었지만 Kafka의 트랜잭션은 메시지 범위만 제어합니다. 트랜잭션 상태에 관계없이 메시지는 즉시 주제로 이동하지만 추가 시스템 속성이 있습니다.

소비자가 이러한 메시지를 미리 읽지 못하도록 하려면 매개변수를 설정해야 합니다. 격리 수준 read_committed 값으로. 이러한 소비자는 이전과 마찬가지로 비트랜잭션 메시지를 읽을 수 있으며 커밋 후에만 트랜잭션 메시지를 읽을 수 있습니다.
이전에 나열된 모든 설정을 지정했다면 정확히 XNUMX회 전송을 구성한 것입니다. 축하해요!

그러나 뉘앙스가 하나 더 있습니다. 위에서 구성한 Transactional.id는 실제로 트랜잭션 접두사입니다. 트랜잭션 관리자에는 시퀀스 번호가 추가됩니다. 수신된 식별자는 다음에게 발급됩니다. transactional.id.expiration.ms, Kafka 클러스터에 구성되며 기본값은 "7일"입니다. 이 시간 동안 애플리케이션이 메시지를 받지 못한 경우 다음 트랜잭션 전송을 시도할 때 메시지를 받게 됩니다. InvalidPidMappingException. 그런 다음 트랜잭션 코디네이터는 다음 트랜잭션에 대한 새 시퀀스 번호를 발급합니다. 그러나 InvalidPidMappingException이 올바르게 처리되지 않으면 메시지가 손실될 수 있습니다.

합계 대신

보시다시피 단순히 Kafka에 메시지를 보내는 것만으로는 충분하지 않습니다. 매개변수 조합을 선택하고 빠른 변경이 가능하도록 준비해야 합니다. 이 기사에서는 정확히 XNUMX회 전달 설정을 자세히 보여주고 우리가 직면한 client.id 및 transactional.id 구성과 관련된 몇 가지 문제를 설명했습니다. 다음은 생산자 및 소비자 설정에 대한 요약입니다.

프로듀서 :

1. ack = 모두
2. 재시도 > 0
3. 활성화.멱등성 = true
4. max.in.flight.requests.per.connection ≤ 5(순서대로 전송하는 경우 1)
5. transactional.id = ${application-name}-${hostname}

소비자:

1. 격리 수준 = read_committed

향후 애플리케이션에서 오류를 최소화하기 위해 나열된 매개변수 중 일부에 대한 값이 이미 설정되어 있는 스프링 구성에 대한 자체 래퍼를 만들었습니다.

다음은 자율 학습을 위한 몇 가지 자료입니다.

• KIP-98 - 정확히 XNUMX회 전달 및 트랜잭션 메시징
• 설정 설명

출처 : habr.com