기본 프리 페치를 사용하여 여러 구독 클라이언트가 실행중인 주제가 있습니다. 클라이언트 중 하나가 느리면 다른 가입 클라이언트의 속도가 느려집니다. 나는 느린 소비자를 위해 프리 페치 (prefetch)를 동적으로 낮추고 싶지만 클라이언트는 무작위로 느려지므로 동적으로 수행해야 할 필요가있다.ActiveMQ - "임의"느린 가입자 - 주제가 가득 차게합니다.
다음 솔루션을 프로토 타입 화하고 싶습니다. 각 구독자에 대한 대기열을 만듭니다. 스레드 풀은 주제에서 이벤트를 제거하고 이벤트를 대기열에 복사합니다. 이제 각 구독자에 대해 대기열이 있으므로 각 클라이언트는 서로 독립적입니다. 각 큐에 대해 프리 페치 제한을 설정합니다. 한도에 도달하면 이벤트를 삭제합니다. 단점 : 메모리가 각 대기열에 필요합니다.
나는 위의 솔루션이나 내 경우에 맞을 것으로 생각되는 다른 솔루션에 대한 의견을 원합니다. 10 개 RPS
이벤트 생성 속도 - 100 개 RPS
기본 프리 페치 제한 : 32000
- :listener1과 처리 속도 : listener2 처리 속도 142 개 RPS
나는 내 유스 케이스에 대한 자세한 내용은 아래를 추가했습니다
사례 1 : 프리 페치 한도가 두 수신기 모두에서 동일 할 때. ~ 761 초 내에 - 주제가 가득 차서 이벤트가 삭제되기 시작합니다.
경우 2 : 느린 소비자의 프리 페치 제한이 빠른 소비자 listener2 프리 페치 제한의 프리 페치 한계보다 작은 경우 : 64K 솔루션 위 잘 작동
하지 때로는 청취자 2 처리 속도 증가와 청취자 일 처리 속도 감소 (처리 속도가 정확히 바뀌지는 않지만 극한 값을 사용하고 있습니다. case2가 작동하지 않는 곳에서 처리하십시오. 지금 listener1 : 10 rps listener2 : 142 rps 토픽이 가득 차서 이벤트 삭제를 시작하는 데 1523 초가 걸린다. 일단 리스너 1이 이벤트를 삭제하기 시작하면 리스너 2와 같은 속도로 처리를 시작합니다.
각 리스너를 독립적으로 실행하고 다른 사용자를 차단하지 않기위한 제안 사항을 찾고 있습니까?
설명서를 읽었지만 producerflowcontrol을 사용할 수 없습니다. 이제는 처리량이 느린 소비자에 달려 있고 느린 소비자는 고정되어 있지 않습니다. 따라서 한 특정 가입자에 대해 보류중인 메시지 제한을 사용할 수 없습니다. 그 suscriber는 시간이 지나면 느려질 수 있습니다. –
더 나은 대답을 원한다면 이미 시도한 것을 문서화하고보고있는 결과가 무엇인지 문서화하는 것이 좋습니다. –
감사의 말을 남긴 Tim. 위의 질문에 대한 자세한 내용을 편집했습니다. –