2014-01-21 18 views
2

저는 클러스터 전체에서 다양한 프로세스를 조절하는 방법을 찾고 있습니다. 이를 위해서는 임의의 수의 이벤트 사용자를 처리 할 수있는 일종의 중앙 집중식 제어가 필요합니다. 내가 가진 생각은 백 로그가없는 특정 속도로 토큰을 생성하는 읽기 전용 대기열을 포함합니다 (누락 된 이벤트는 그냥 버려집니다). 예를 들어, 시간당 10,000 개의 메시지로 조절해야하는 웹 API가 있지만 클러스터의 모든 서버에서 호출 할 수 있다고 가정 해보십시오. 10k 메시지/시간에 토큰을 생성하도록 큐를 구성하고 모든 서버는 해당 큐에 연결하여 진행하기 전에 토큰을 검색합니다. 이는 대기 시간 (첫 번째 요청 후 3600/10000 초)을 도입하지만 소비자 수에 관계없이 원활하고 예측 가능할 것입니다. 나는 조용한 기간 후에 서두를 갖고 싶지 않기 때문에 백 로그를 갖고 싶지 않습니다. 목표는 단지 ​​시간당 총 이벤트 수를 제한하는 것이 아니라 그 시간 간격으로 균등하게 확산시키는 것입니다.분산 이벤트 제한을위한 읽기 전용 대기열?

내 주요 응용 프로그램은 PHP이고 리눅스에서 실행 중입니다. 현재 나는 일반적인 대기열 처리를 위해 Beanstalkd에 만족하지만이 작업 모드를 지원하지 않습니다. 나는 과거에 RabbitMQ를 사용 했었지만 비교해 보면 무겁고 깨지기 쉬운 것을 발견했습니다. 구성 후에 외부 입력이 필요 없기 때.에 큐 관리자 자체가이를 수행 할 수 있으면 좋을 것입니다.

이와 같은 특정 지원이없는 상황에서 매우 짧은 만기와 함께 토큰을 밀어 넣는 프로세스가있는 일반 대기열을 사용해 볼 수도 있습니다.하지만 매우 유쾌하지는 않습니다. 더 좋은 아이디어?

답변

0

당신이 중 하나를 사용할 수는 접근 :

  1. 사용 주제 일반 큐와 교환하지만, 설정 메시지 ttl를 여러분의 필요에. 이 방법의 장점은 지난 5 초 동안 작은 백로 그램을 유지할 수 있다는 것입니다.이 기능을 사용하면 유지 관리 중에 네트워크가 손실되는 등 짧은 시간 문제가 발생해도 응용 프로그램을 복구 할 수 있습니다. 단점은 없습니다.

  2. 메시지를 팬 아웃 교환에 게시하고 auto-delete 플래그로 대기열을 선언 한 다음 메시지를 소비 할 수 있습니다. 이 방식의 가장 큰 단점은 메시지가 대기열을 통해 중복된다는 점입니다. 실제로 이러한 동작이 필요한 경우에는 유용 ​​할 수 있지만 동일한 바인딩을 사용하는 추가 대기열을 사용하여 쉽게 주제를 교환 할 수 있습니다.

+0

메시지의 중복은 중요하지 않습니다. 중요한 것은 토큰의 가용성입니다. 어떤 내용이나 의미가 전혀 필요하지 않습니다. 큐가 자체 토큰을 생성 할 수 있다면 실제로 메시지 입력이 전혀 필요하지 않습니다. 과거에 토끼 문제가 너무 많아서 토끼를 사용하고 싶지 않습니다. – Synchro