RabbitMQ 섹션 요약

RabbitMQ 개념의 channel, exchange,queue.

Queue는 자신의erlang 프로세스를 가지고 있습니다.exchange 내부에서binding 관계를 저장하는 검색표를 구현합니다.channel은 실제 루트 작업을 진행하는 실체입니다. 즉routing_에 따라key는queue에게 메시지를 보냅니다.AMQP 프로토콜 설명을 통해 알 수 있듯이 채널은 실제 TCP 연결 위의 가상 연결입니다. 모든 AMQP 명령은 채널을 통해 발송되고 모든 채널은 유일한 ID를 가지고 있습니다.하나의 채널은 하나의 운영체제 라인에서만 사용할 수 있기 때문에 특정 채널에 보내는 메시지는 순서가 있습니다.그러나 하나의 운영체제 라인에서 여러 개의 채널을 사용할 수 있습니다.

메시지 배포

만약 이 대기열에 최소한 한 명의 소비자가 구독한다면, 메시지는 순환 (round-robin) 방식으로 소비자에게 발송될 것이다.모든 메시지는 구독한 소비자에게만 나누어진다(전제는 소비자가 정상적으로 메시지를 처리하고 확인할 수 있다는 것이다)

메시지 라우팅

개념적으로 말하자면 메시지 루트는 반드시 세 가지 부분이 있어야 한다. 그것이 바로 교환기, 루트, 귀속이다.생산자가 정보를 교환기에 발표하기;귀속은 메시지가 공유기에서 특정한 대기열로 어떻게 이동하는지 결정합니다.소식이 마침내 대열에 도착하여 소비자에게 접수되었다.
메시지가 교환기에 발표될 때, 메시지는 라우팅 키 (routing key) 를 가지고 있으며, 메시지가 생성될 때 설정됩니다.대기열 루트 키를 통해 대기열을 교환기에 연결할 수 있습니다.메시지가 교환기에 도착하면 RabbitMQ는 메시지의 라우팅 키를 대기열의 라우팅 키와 일치시킵니다.대기열에 일치할 수 있으면 메시지가 해당 대기열에 전송됩니다.대기열과 일치하지 않으면 메시지가 "블랙홀"으로 들어갑니다.
자주 사용하는 교환기는 주로 세 가지로 나뉜다.
fanout: 방송 모드 대기열이 이 교환기를 직접 연결합니다. (routing key를 지정할 필요가 없습니다.)
예:

BindingBuilder.bind(Message_1).to(fanoutExchange);

BindingBuilder.bind(Message_2).to(fanoutExchange)；

대기열 1과 2는 스위치 fanoutExchange에서 메시지를 받을 수 있습니다.
direct: binding 키와routing 키가 완전히 일치하는Queue로 메시지 라우팅
예:
생산자가 메시지를 보낼 때bing-key를 지정해야 합니다

rabbitTemplate.convertAndSend(directExchange,"bind-key", goJson.toJSONString());

BindingBuilder.bind(AMessage).to(directExchange).with("bind-key");

대기열 AMessage는 bind-key를 사용하여 directExchange 스위치에 바인딩

메시지가 RabbitMQ로 올바르게 전송되는지 확인

방안 1: 사무 메커니즘
이 단계의 신뢰성을 확보하기 위해 AMQP 프로토콜은 설립 초기에 사무 메커니즘을 제공했다.RabbitMQ 클라이언트에서 트랜잭션 메커니즘과 관련된 방법은 세 가지가 있습니다: channel.txSelect、channel.txCommit 및 channel.txRollback.channel.txSelect는 현재 채널을 사무 모드로 설정하는 데 사용됩니다.channel.txCommit는 트랜잭션을 커밋하는 데 사용되며 channel.트랜잭션 롤백은 트랜잭션 롤백에 사용됩니다.채널을 통해서txSelect 방법이 사무를 시작한 후에 우리는 RabbitMQ에 메시지를 발표할 수 있습니다. 만약에 사무 제출이 성공한다면 메시지는 반드시 RabbitMQ에 도착할 것입니다. 만약에 사무 제출이 실행되기 전에 RabbitMQ가 이상하게 붕괴되거나 다른 원인으로 이상을 던지면 이 때 우리는 이를 포착하여 채널을 실행할 수 있습니다.트랜잭션 롤백을 위한 txRollback 메서드

try {
  //  
  channel.txSelect();
  //  
  channel.basicPublish(exchange, routingKey, props, body);
  //  
  channel.txCommit();
} catch(Exception e) {
  //  
  channel.txRollback();
  e.printStackTrace();
}

시나리오 2: Confirm 메커니즘
RabbitMQ는 발송자 확인 모드를 사용하여 메시지가 RabbitMQ로 정확하게 전송되는지 확인합니다.송신자 확인 모드: 채널을confirm 모드(송신자 확인 모드)로 설정하면 채널에 발표된 모든 메시지에 유일한 ID가 할당됩니다.메시지가 목적 대기열에 전송되거나 디스크에 기록된 후 (지속화 가능한 메시지) 채널은 생산자에게 확인 메시지를 보냅니다. (메시지 유일한 ID 포함)RabbitMQ에서 내부 오류가 발생하여 메시지를 잃어버리면 nack (not acknowledged, 확인되지 않음) 메시지가 전송됩니다.송신자 확인 모드는 비동기적이며 생산자 응용 프로그램은 확인을 기다리는 동시에 메시지를 계속 보낼 수 있다.확인 메시지가 생산자 응용 프로그램에 도착하면 생산자 응용 프로그램의 리셋 방법이 터치되어 확인 메시지를 처리합니다.
Exchange가 대기열에 일치하지 않으면 메시지가 손실됩니다.
mandatory
mandatory 매개 변수가true로 설정되었을 때, Exchange가 자신의 유형과 루트 키에 따라 조건에 맞는 대기열을 찾을 수 없다면, RabbitMQ는 Basic를 호출합니다.Return 명령은 메시지를 생산자에게 반환합니다.mandatory 매개 변수가false로 설정되었을 때 상기 상황이 발생하면 메시지는 바로 버려집니다.이때 채널을 호출할 수 있습니다.addReturnListener에서 ReturnListener 모니터를 추가하여 적절한 대기열에 대한 올바른 경로가 없음을 알 수 있습니다.
백업 교환기
백업 교환기를 사용하면 라우팅되지 않은 메시지를 RabbitMQ에 저장하고 필요할 때 처리할 수 있습니다.성명 교환기 (channel.exchangeDeclare 방법 호출) 를 사용할 때alternate-exchange 매개 변수를 추가해서 실행할 수 있습니다.모든 교환기에 같은 백업 교환기를 설정할 수 있습니다. 정확한 루트가 없는 모든 메시지는 이 백업 교환기에 전송되지만, 백업 교환기가 정확하게 대기열에 연결되어 있는지 확인해야 합니다.백업 교환기와mandatory 파라미터를 함께 사용하면 mandatory 파라미터가 무효입니다.

 Map<String,Object> arguments = new HashMap<String,Object>();
 	arguments.put("alternate-exchange"," Name");
 	channel.exchangeDeclare(EXCHANGE_NAME,"fanout",true,false,arguments);

어떻게 정보 수신자가 정보를 소비하도록 확보합니까?

수신자 메시지 확인 메커니즘: 소비자가 모든 메시지를 받은 후에 반드시 확인을 해야 한다(메시지 수신과 메시지 확인은 두 가지 다른 조작이다).소비자가 메시지를 확인해야만 Rabbit MQ가 안전하게 메시지를 대기열에서 삭제할 수 있습니다.여기에는 시간 초과 메커니즘이 사용되지 않습니다. RabbitMQ는 Consumer의 연결 중단을 통해서만 메시지를 다시 보내야 하는지 확인합니다.연결이 끊기지 않는 한 Rabbit MQ는 소비자에게 메시지를 처리하는 데 충분한 시간을 주었다는 것이다.autoAck 매개 변수를 지정할 수 있습니다. autoAck이false와 같을 때 RabbitMQ는 소비자가 확인 신호에 현저하게 대답할 때까지 기다린 후에 메모리(또는 디스크)에서 메시지를 옮깁니다.autoAck이true와 같을 때 RabbitMQ는 전송된 메시지를 자동으로 확인으로 설정하고 메모리(또는 디스크)에서 삭제합니다. 소비자가 이 메시지를 실제로 소비하든 말든.
다음은 몇 가지 특수한 상황을 나열한다.
만약 소비자가 메시지를 받고 확인하기 전에 연결을 끊거나 구독을 취소하면 Rabbit MQ는 메시지가 배달되지 않았다고 생각하고 다음 구독자에게 다시 배달됩니다.(메시지 중복 소비의 위험이 있을 수 있으므로bizId에 따라 중복해야 함)
만약 소비자가 메시지를 받았지만 확인하지 않고 연결이 끊기지 않았다면 Rabbit MQ는 이 소비자가 바쁘기 때문에 이 소비자에게 더 많은 정보를 나누어 주지 않을 것이라고 생각했다.
만약에 RabbitMQ가 리셋을 기다리는 과정에서 소비자 서비스가 끊어진다면 RabbitMQ의 경우 대기열의 메시지는 두 부분으로 나뉜다. 일부는 소비자에게 전달되기를 기다리는 메시지이다.일부는 이미 소비자에게 배달됐지만 아직 소비자 확인 신호를 받지 못했다.만약 RabbitMQ가 소비자로부터 확인 신호를 받지 못하고 이 메시지를 소비하는 소비자가 연결을 끊었다면, RabbitMQ는 이 메시지를 다시 대기열에 넣고 다음 소비자에게 배달하기를 기다릴 것입니다.RabbitMQ가 이 메시지를 다시 배달해야 하는지 판단하는 유일한 근거는 이 메시지를 소비하는 소비자의 연결이 끊어졌는지 여부이다. 이런 디자인은 소비자들이 하나의 메시지를 오랫동안 소비할 수 있도록 한다.메시지 소비에 실패하면 Basic를 호출할 수도 있습니다.Reject 또는 Basic.Nack은 현재 메시지를 거부합니다. 그러나 주의해야 할 것은 간단한 거부만 하면 메시지가 분실됩니다. 해당하는 requeue 인자를true로 설정해야 RabbitMQ가 이 메시지를 다시 대기열에 저장할 수 있습니다.만약requeue 매개 변수가false로 설정된다면rabbitMQ는 메시지를 대기열에서 제거하고 새로운 소비자에게 보내지 않습니다.