2013-03-16 4 views
1

기본 프리 페치를 사용하여 여러 구독 클라이언트가 실행중인 주제가 있습니다. 클라이언트 중 하나가 느리면 다른 가입 클라이언트의 속도가 느려집니다. 나는 느린 소비자를 위해 프리 페치 (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와 같은 속도로 처리를 시작합니다.

각 리스너를 독립적으로 실행하고 다른 사용자를 차단하지 않기위한 제안 사항을 찾고 있습니까?

답변

1

느린 소비자를 다루기 위해 ActiveMQ 페이지에서 documentation을 보았습니까? 기본적으로 전략은 보류중인 메시지 제한 전략을 사용하여 브로커가 느리게 이동하여 백업을 발생시키는 고객을 위해 이전 메시지를 버리기 시작하는 것입니다. 느린 소비자가 브로커에 메시지를 생성하게되므로 구성 한계에 도달하기 시작하여 브로커가 생산자를 늦출 수 있습니다. 보류중인 메시지 제한을 적용하면 빌드 속도가 느려지는 것을 방지 할 수 있습니다.

생산자 흐름 제어를 해제하여 생산자가 정상 속도를 유지하고 디스크가 한계에 도달 할 때까지 메시지를 디스크에 스풀링하도록 할 수도 있습니다. 이는 documentation에서도 다루고 있습니다.

+0

설명서를 읽었지만 producerflowcontrol을 사용할 수 없습니다. 이제는 처리량이 느린 소비자에 달려 있고 느린 소비자는 고정되어 있지 않습니다. 따라서 한 특정 가입자에 대해 보류중인 메시지 제한을 사용할 수 없습니다. 그 suscriber는 시간이 지나면 느려질 수 있습니다. –

+0

더 나은 대답을 원한다면 이미 시도한 것을 문서화하고보고있는 결과가 무엇인지 문서화하는 것이 좋습니다. –

+0

감사의 말을 남긴 Tim. 위의 질문에 대한 자세한 내용을 편집했습니다. –