메시지 대기열의 고가용성을 어떻게 보장합니까?

메시지 큐는 동시성이 높은 시나리오에서 필수적인 기술입니다. 이를 사용함에 따라 프로덕션 환경에는 다음과 같은 많은 문제가 있습니다. 메시지 큐의 고가용성을 달성하는 방법은 무엇입니까?

시나리오에는 다양한 유형의 미들웨어가 있습니다. 여기서는 분석 및 처리를 위해 일반적으로 사용되는 미들웨어를 준비합니다.

1. RabbitMQ의 고가용성

RabbitMQ는 마스터-슬레이브(비분산) 고가용성을 기반으로 하기 때문에 비교적 대표적인 것입니다. 첫 번째 유형의 고가용성을 달성하는 방법을 RabbitMQ를 예로 들어 설명하겠습니다. MQ의 달성.

RabbitMQ에는 독립형 모드, 일반 클러스터 모드, 미러 클러스터 모드의 세 가지 모드가 있습니다.

싱글 플레이어 모드

싱글 플레이어 모드는 데모 수준이며 일반적으로 재미를 위해 로컬에서 시작하며 프로덕션을 위해 독립 실행형 모드를 사용하는 사람은 없습니다.

일반 클러스터 모드(고가용성 없음)

일반 클러스터 모드는 각 시스템마다 하나씩 여러 시스템에서 여러 RabbitMQ 인스턴스를 시작하는 것을 의미합니다. 생성한 큐는 하나의 RabbitMQ 인스턴스에만 배치되지만 각 인스턴스는 큐의 메타데이터를 동기화합니다. (메타데이터는 큐의 일부 구성 정보라고 생각할 수 있습니다. 메타데이터를 통해 큐가 있는 인스턴스를 찾을 수 있습니다.) .

소비할 때 실제로 다른 인스턴스에 연결된 경우 해당 인스턴스는 대기열이 있는 인스턴스에서 데이터를 가져옵니다.

이 방법은 정말 번거롭고 별로 좋지 않습니다. 소위 배포를 달성하지 못하고 단지 일반적인 클러스터입니다. 이로 인해 소비자는 매번 인스턴스에 무작위로 연결하여 데이터를 가져오거나, 소비자가 대기열이 있는 인스턴스에 고정적으로 연결하여 데이터를 소비하게 되고, 후자는 데이터를 가져오는 오버헤드가 발생하게 됩니다. 단일 인스턴스 성능 병목 현상.

그리고 대기열을 넣은 인스턴스가 다운되면 다른 인스턴스가 해당 인스턴스에서 가져올 수 없습니다. 메시지 지속성을 활성화하고 RabbitMQ가 메시지를 저장하도록 하면 이 인스턴스를 기다려야 할 수 있습니다. 복원된 후 이 대기열에서 계속 데이터를 가져올 수 있습니다.

이 문제는 더 당황스럽습니다. 이 솔루션은 주로 처리량을 향상시키는 것, 즉 클러스터의 여러 노드가 특정 대기열의 읽기 및 쓰기 작업을 제공할 수 있도록 하는 것입니다.

미러 클러스터 모드(고가용성)

이 모드는 소위 RabbitMQ의 고가용성 모드입니다. 일반 클러스터 모드와 다른 점은 미러 클러스터 모드에서는 대기열의 메타데이터나 메시지에 관계없이 생성한 대기열이 여러 인스턴스에 존재한다는 것입니다. 즉, 각 RabbitMQ 노드에는 이 대기열의 완전한 복사본이 있습니다. 미러링은 대기열의 모든 데이터를 포함하는 것을 의미합니다. 그러면 대기열에 메시지를 쓸 때마다 메시지가 여러 인스턴스의 대기열에 자동으로 동기화됩니다.

이 미러 클러스터 모드를 활성화하는 방법은 무엇입니까? 실제로 RabbitMQ에는 백그라운드에 정책을 추가하는 좋은 관리 콘솔이 있습니다. 이 정책을 지정하면 데이터를 모든 노드에 동기화하도록 요구할 수 있습니다. 노드가 대기열을 다시 생성할 때 이 전략을 적용하면 데이터가 다른 노드에 자동으로 동기화됩니다.

이 경우 장점은 머신 중 하나가 다운되더라도 괜찮다는 것입니다. 다른 머신(노드)에는 여전히 이 대기열의 전체 데이터가 포함되어 있으며 다른 소비자는 다른 노드로 이동하여 데이터를 사용할 수 있습니다.

단점은 첫째, 성능 오버헤드가 너무 높다는 점입니다. 메시지를 모든 시스템에 동기화해야 하므로 네트워크 대역폭에 대한 부담과 소비가 커집니다.

둘째, 이러한 게임이 배포되지 않으면 확장성이 없습니다. 대기열의 로드가 너무 많아 시스템을 추가하면 새 시스템에도 대기열의 모든 데이터가 포함됩니다.

2. Kafka의 고가용성

Kafka의 기본 아키텍처 이해: 여러 브로커로 구성되며, 각 브로커는 주제를 생성하는 노드이며, 이 주제는 여러 파티션으로 나눌 수 있습니다. 서로 다른 브로커에 존재할 수 있으며 각 파티션은 데이터의 일부를 저장합니다.

이것은 자연스러운 분산 메시지 대기열입니다. 즉, 주제의 데이터가 여러 시스템에 분산되어 있고 각 시스템이 데이터의 일부를 저장한다는 의미입니다.

사실 RabbitMQ 등은 분산된 메시지 대기열이 아닙니다. 그들은 단지 일부 클러스터링 및 HA(고가용성, 고가용성) 메커니즘을 제공할 뿐입니다. 왜냐하면 어떻게 플레이하든 RabbitMQ는 다음과 같은 데이터이기 때문입니다. 대기열은 미러 클러스터 아래의 한 노드에 배치되며 각 노드는 대기열의 전체 데이터도 저장합니다.

Kafka 0.8 이전에는 HA 메커니즘이 없었습니다. 브로커가 다운되면 해당 브로커의 파티션은 쓸모가 없으며 고가용성이 전혀 없었습니다.

예를 들어, 주제를 생성하고 파티션 수를 3개 머신에 각각 3개로 지정한다고 가정합니다. 그러나 두 번째 머신이 다운되면 이 주제에 대한 데이터의 1/3이 손실되므로 가용성이 높을 수 없습니다.

Kafka 0.8 이상에서는 복제( 복제본) ) 복사 메커니즘. 각 파티션의 데이터는 다른 시스템과 동기화되어 자체 다중 복제본을 형성합니다. 모든 복제본은 리더를 선택하고 생산 및 소비는 이 리더를 처리하며 다른 복제본은 팔로어가 됩니다. 글을 쓸 때 리더는 모든 팔로워에게 데이터를 동기화할 책임이 있습니다. 읽을 때는 리더의 데이터를 직접 읽으세요. 리더만 읽고 쓸 수 있나요?

매우 간단합니다. 각 팔로어를 마음대로 읽고 쓸 수 있다면 데이터 일관성 문제를 처리해야 합니다. 시스템 복잡도가 너무 높아 문제가 발생하기 쉽습니다. Kafka는 내결함성을 향상시키기 위해 파티션의 모든 복제본을 다른 시스템에 균등하게 배포합니다.

이렇게 하면 소위 고가용성이 있습니다. 누군가 브로커가 다운되었지만 해당 브로커의 파티션은 다른 시스템에 복제되었습니다. 다운된 브로커에 특정 파티션의 리더가 있는 경우 팔로어 중에서 새 리더가 다시 선출되며 모든 사람은 계속해서 새 리더를 읽고 쓸 수 있습니다. 이를 고가용성이라고 합니다.

데이터를 쓸 때 프로듀서가 리더에 쓰고, 리더가 로컬 디스크에 데이터를 쓰고, 다른 팔로워가 주도적으로 리더에서 데이터를 가져옵니다. 모든 팔로어가 데이터를 동기화하면 리더가 모든 팔로어로부터 ack를 받은 후 성공적으로 작성된 메시지를 생산자에게 반환합니다. (물론 이것은 모드 중 하나일 뿐이며 이 동작은 적절하게 조정될 수 있습니다)

소비 시 리더에서만 읽을 수 있지만 모든 팔로어가 메시지를 동기화한 경우에만 가능합니다. , ack가 성공적으로 반환되면 소비자가 이 메시지를 읽게 됩니다.

관련 PHP 지식을 더 보려면 php 튜토리얼을 방문하세요!

위 내용은 메시지 대기열의 고가용성을 어떻게 보장합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!