고 가용성
Chris가 언급했듯이 API 서버는 레이아웃에서 단일 실패 지점입니다. 당신이 설정하는 것은 많은 사람들이 이전에 구현 한 메시지 큐 인프라입니다.
같은 길을 계속
API 서버에서 요청 수신을 언급하고 각 서버에서 실행중인 MySQL DB에 작업을 삽입하십시오. 이 경로를 계속하려면 API 서버 계층을 제거하고 API 사용자로부터 직접 명령을 수락하도록 Workers를 디자인하는 것이 좋습니다. 라운드 로빈 DNS처럼 간단한 것을 사용하여 각 API 사용자 연결을 사용 가능한 작업자 노드 중 하나로 직접 배포하고 연결에 실패하면 다시 시도 할 수 있습니다.
Message Queue 서버 사용
보다 강력한 메시지 큐 인프라는 ActiveMQ 와 같은 이러한 목적으로 설계된 소프트웨어를 사용합니다 . ActiveMQ의 RESTful API를 사용하여 API 사용자의 POST 요청을 수락 할 수 있으며 유휴 작업자는 큐에서 다음 메시지를받을 수 있습니다. 그러나 이것은 아마도 사용자의 요구에 너무 과도 할 수 있습니다. 초당 대기 시간, 속도 및 수백만 개의 메시지를 위해 설계되었습니다.
사육사 사용
미들 그라운드로서, 당신은 Zookeeper를 특별히 볼 수 있습니다. 비록 그것이 메시지 큐 서버는 아닙니다. 이 정확한 목적을 위해 $ work에 사용합니다. Zookeeper 서버 소프트웨어를 실행하는 3 개의 서버 세트 (API 서버와 유사)가 있으며 사용자 및 애플리케이션의 요청을 처리하기위한 웹 프론트 엔드가 있습니다. 웹 프론트 엔드와 작업자에 대한 Zookeeper 백엔드 연결에는 유지 보수를 위해 서버가 다운 된 경우에도 큐를 계속 처리 할 수 있도록로드 밸런서가 있습니다. 작업이 완료되면 작업자는 Zookeeper 클러스터에 작업이 완료되었음을 알립니다. 작업자가 사망하면 해당 작업이 다른 작업으로 전송되어 완료됩니다.
다른 관심사
- 근로자가 응답하지 않을 경우 작업을 완료해야합니다
- API는 작업이 완료되었음을 작업자에게 알리고 작업자 데이터베이스에서 검색하는 방법은 무엇입니까?
- 복잡성을 줄이십시오. 각 작업자 노드에 독립적 인 MySQL 서버가 필요합니까, 아니면 API 서버의 MySQL 서버 (또는 복제 된 MySQL 클러스터)와 통신 할 수 있습니까?
- 보안. 누구든지 직업을 제출할 수 있습니까? 인증이 있습니까?
- 다음 직장을 구해야 할 근로자는? 작업이 10ms 또는 1 시간이 걸릴 것으로 예상되는지 언급하지 않습니다. 속도가 빠르면 지연 시간을 줄이기 위해 레이어를 제거해야합니다. 속도가 느리면 짧은 요청이 몇 개의 오래 실행되는 요청 뒤에 걸리지 않도록 매우주의해야합니다.