RabbitMqqos prefetch 메시지 차단 문제

mq는 코드 확장을 실현하는 유리한 수단으로 개인은 개념으로 새로운 지식을 배우고 문제를 막기 전에 개념의 학습을 먼저 한다.
ConnectionFactory:connection을 만드는 공장 클래스
Connection: socket으로 간단히 이해하기
채널: mq와 상호작용하는 인터페이스,queue,exchange와 귀속queue,exhange 등 인터페이스를 정의합니다.
다음은 mq와의 상호작용 클래스입니다.
exchange: 간단하게 루트를 보면 유형이 중요하지 않습니다. 홈페이지를 보면 됩니다.
queue: 클라이언트가 감청하는 것은queue입니다. exchange가 아니라,queue를 사용하는 전제는 exchange와queue를 연결해야 합니다.자바queue 도구류를 사용하면 쉽게 시작할 수 있다.queue는 쓰기와 읽기로 나뉘는데 각자 주파수가 있고 빨리 읽는 것이 느리고 막히기 쉽다.느리게 쓰고 빨리 읽으면 소비자의 여가를 조성하기 쉽다.
Prefetc: 중요하지만 무시되기 쉬운 지표이자 이번에 겪은 문제입니다.prefetch와 메시지 배달
prefetch는 단일 소비자가 가장 많이 소비할 수 있는 unacked 메시지 수를 가리킨다.
어떻게 이해합니까?
mq는 모든consumer에 버퍼를 설정합니다. 크기는prefetch입니다.메시지를 받을 때마다 MQ는 메시지를 캐시 영역으로 전송한 다음 클라이언트에게 전송합니다.ack 메시지를 받았을 때 (consumer가baseack 명령을 보냄) mq는 버퍼에서 위치를 비우고 새로운 메시지를 추가합니다.그러나 이때 버퍼가 꽉 차면 MQ는 막힌 상태로 들어간다.
더 구체적으로 설명하자면prefetch 값을 10으로 설정하면 모두 두 개의consumer가 있다.즉, 각각consumer는queue에서 10개의 메시지를 미리 캡처하여 로컬에 캐시하여 소비를 기다린다는 것이다.이 채널의 unacked 수는 20이 됩니다.Rabbit 배달의 순서는 먼저consumer1에 10개의 메시지를 가득 채우고consumer2에 10개의 메시지를 배달하는 것이다.만약 이 때 새로운 메시지가 배달되어야 한다면, 채널의 unacked 수가 20인지 아닌지를 판단하고, 만약 그렇다면, 메시지를consumer에 배달하지 않을 것입니다. 메시지는queue에 계속 있습니다.이후 그 중에서consumer는 한 가지 메시지에 대해ack를 한다. unacked는 이때 19와 같고 Rabbit는 어느 consumer의 unacked가 10보다 적은지 판단하여 어느 consumer에 배달한다.
내가 직면한 문제는 부주의한 프로그래머이다. 코드를 작성할 때, 그가 어떤 메시지 처리 방식에 대해 이렇게 하는 것이다

  if (success) {
                        channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
                    } else {
                        logger.error("######### The message is not delete from queue : {}", body);
                    }

먼저 그는ack 메커니즘을 수동으로 설정한 다음에 그의 이해는 만약에 성공한 소식을 처리한다면ack는 MQ에게 주고 MQ가 완성된 데이터를 삭제할 수 있기를 기대한다는 것이다.그렇지 않으면 보존 데이터가 다시 처리된다.
이 오류는 ack에 대한 이해입니다. 실패할 때 프로그램을 계속 처리해야 한다면 basicNack을 사용하고 mq에 메시지를 다시 대기열에 넣어야 합니다.

    if (success) {
                            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
                        } else {
                            channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
                        }

클라이언트가 의외로 다운되는 경우ack 서버가 없으면 데이터를 삭제하지 않지만consumer가 리셋한 후에 서버는 새로운 소비자이다. 즉, 버퍼가 원래의 n-prefetch로 리셋되기 때문에 이 문제는 부주의한 형이 당연하게 테스트를 통과했다.
prefetch의 크기는 얼마여야 합니까
이 글은 아주 좋은 건의를 주었으니, 나는 간단하게 나의 이해를 말해 보겠다.
이상적인 상황에서 MQ 서버가 버퍼에서 메시지를 받아 소비단으로 보내는 시간을 계산하고 소비단이ack 메시지를 MQ 서버로 처리하는 시간을 계산하면 100ms로 가정한다. 그 중에서 소비단이 업무를 처리하는 데 10ms의 비용이 든다.
여기에서 우리prefetch=100ms/10ms=10, 즉 메시지가 왔다 갔다 하는 총 시간/업무 처리 시간을 알 수 있습니다. 여기에서prefetch>=10을 요구합니다.보통 이 시간을 계산하는 것은 정확하지 않고 고모님만 계산할 수 있기 때문에prefetch는 일반적으로 좀 커야 한다.그러나 이 값도 너무 크면 안 된다. 그렇지 않으면 소비단은 한가한 상태에 처하게 된다.
그래서 만약에 모든 소식이 ack가 되었다고 보증하지만 비교적 긴 시간 동안 막힌다면 prefetch를 늘리거나 기계를 더 늘리거나 업무 처리 시간을 줄이세요.처음에는 이러한 업무 논리를 처리하기 위해 또는 하나의 스레드 탱크를 사용하는 것을 권장했다.