RabbitMq 메시지를 잃지 않는 방법

지난 편에서는 Rabbitmq를 파악하는 몇 가지 중요한 개념을 썼는데, 한 가지 소식부터 말하자면, 이 소식은 소식의 분실로 인해 골치 아픈 일을 정리한다.네트워크 장애, 서버 재부팅, 하드 드라이브 손상 등으로 인해 메시지가 손실됩니다.소식은 생산에서 소비까지의 주요 결과 아래 몇 단계는 다음과 같다.
① 생산 단계에서 생산자가 메시지를 만들고 네트워크를 통해rabbit 서버에 전송
② 메시지 저장 단계에서 교환기에 먼저 전송된 후 라우팅 알고리즘을 통해 대기열에 도달하여 소비가 늘어나기를 기다린다
③ 소비 단계에서 소비자는 인터넷을 통해 래빗 서버에서 정보를 가져와 소비한다
이 세 단계 모두 메시지가 분실될 수 있으니 아래에서 하나하나 분석합시다.
메시지 저장 단계
정상적인 상황에서 우리는 BasicPublish 방법으로 메시지를 교환기에 보내고 대기열에 루트합니다. 소비자들은 아직 소비를 하지 않았습니다. 이때 서버가 리셋되었습니다. (대기열, 교환기는 기본적인 창설 방식을 사용합니다.) 무슨 일이 일어날까요?답은 메시지 분실입니다.이유는 간단하다. 메시지는 메모리에 있고 디스크가 없고, 기본적으로 비지구적이며, 서비스가 재개된 후에 다시 만들어야 하기 때문에 메시지는 자연히 잃어버린다!
다행히도 Rabbit는 지속화된 메커니즘을 제공합니다. 대기열, 교환기가 생성될 때durable 속성은true로 설정하고 메시지 배달 모드(delivery mode)는 2로 설정하면 메시지가 지속적으로 표시됩니다.이렇게 하면 서버 리셋 메시지가 분실되는 상황을 피할 수 있다.
발송 단계
발표 조작이 생산자에게 어떤 정보도 되돌려 주지 않기 때문에, 서버가 하드디스크에 지속적인 메시지를 보냈는지 어떻게 알 수 있습니까?서버가 메시지를 디스크에 쓰기 전에 다운되었을 수도 있습니다. 이로 인해 메시지가 분실되었습니다!
있습니다.
Rabbit는 두 가지 해결 방안, 사무를 제공하지만 성능이 크게 떨어지고 생산자 응용 프로그램을 동기화할 수 있습니다.생산 환경은 일반적으로 채택하지 않는다.또 다른 방안은 확인 모델이다.간단하다. 모든 일치하는 구독 대기열에 메시지 루트를 주고 나면 비동기적으로 생산자에게 알려준다.채널 사용.ConfirmSelect() 메서드를 사용하여 채널을 확인 모드로 엽니다.그리고 두 개의 리셋 함수,ack와nack 이벤트를 주입합니다.

channel.BasicAcks += (sender, ev) =>
                {
                    Console.WriteLine(" " + ev.DeliveryTag);

                };

                channel.BasicNacks += (sender, ev) =>
                {
                    Console.WriteLine(" " + ev.DeliveryTag);
                };

소비 단계
너는 소비단의 소식을 어떻게 잃어버릴 수 있느냐고 물어볼 수도 있다.Rabbitmq는 자동으로 및 수동으로 메시지를 확인하고 메시지를 대기열에서 제거합니다.만약에 autoAck이true이고 자동 확인 모드라면 서버는 메시지를 소비단에 보낸 후 자동으로 출대합니다.만약 어떤 이유로 연결이 끊겼거나 당신의 소비단 응용 프로그램에 고장이 났다면 메시지는 잃어버릴 것입니다!
AutoAck을 false로 설정하여 수동으로 확인하여 서버에 메시지가 처리되었음을 알리고 메시지 행렬을 삭제할 수 있습니다.

 channel.BasicConsume(queue: queueName,
                                     autoAck: false,
                                     consumer: consumer);
 consumer.Received += (model, ea) =>
                {
                    //dosometing
                    channel.BasicAck(ea.DeliveryTag, false);// 
                };

소결: 이상의 처리를 했다면 소식은 너에게 숨지 않았을 거야.여기에 성능 문제가 있습니다. 메시지가 오래 지속되는 것은 디스크에 긁히는 것이 배달 속도에 영향을 주고 메시지 확인도 배달 속도에 영향을 줄 수 있습니다.기본적으로 수요를 만족시킬 수 있는 것은 아니다.만약 성능 수요를 만족시키지 못한다면 다른 방법을 사용할 수 있다. 예를 들어 메시지를 보낼 때마다 응답 대기열의 이름을 포함하면 소비자들은 응답을 다시 보내서 받아들임을 확인할 수 있다.만약 메시지 응답이 합리적인 시간 범위 내에 도착하지 않으면 생산자는 다시 메시지를 발송한다.