2
우리는 Spring을 사용하여 단일 노드와 잘 작동하는 예약 된 작업을 실행합니다. 우리는 N 노드의 클러스터에서 이러한 예약 된 작업을 실행하여 작업이 한 시점에서 한 노드 씩 실행되도록합니다. 이것은 엔터프라이즈 사용 사례를위한 것이며 최대 10 ~ 20 개의 노드를 기대할 수 있습니다.zookeeper를 사용하는 클러스터의 예약 된 작업
- 사용 석영 클러스터에서 예약 된 작업을 실행하기위한 인기있는 선택이 될 것 같다 나는 다양한 옵션으로 보았다. 단점 : 피하고자하는 데이터베이스 종속성.
- 사육사를 사용하고 항상 리더/마스터 노드에서만 예약 된 작업을 실행하십시오. 단점 : 작업 실행로드가 배포되지 않음
- zookeeper를 사용하고 모든 노드에서 예약 된 작업을 호출하도록하십시오. 그러나 작업이 실행되기 전에 실행이 완료되면 분산 잠금 및 릴리스를 확보해야합니다. 단점 : 응용 프로그램에 과부하가 발생하여 시스템 시계가 드리프트되는 경우 문제가 될 수있는 모든 노드의 시스템 시계가 동기화되어 있어야합니다.
- zookeeper를 사용하여 마스터 노드가 일정에 따라 작업을 계속 생성하고 임의의 작업자에게 할당하도록합니다. 이전 예약 된 작업이 아직 수행되지 않은 경우 새 작업이 할당되지 않습니다. 단점 : 너무 복잡해 보입니다.
사육사 앙상블 노드가 NTP를 사용하여 동기화 된 시스템 클럭으로 별도의 클러스터에서 실행된다고 가정하면 안전한 해결책 인 것으로 보이는 # 3을 사용하는 경향이 있습니다. 또한 시스템 클록이 동기화되면 모든 노드가 작업을 실행하기 위해 잠금을 획득 할 수있는 기회가 동일하다는 가정하에 있습니다.
편집 : 좀 더 생각한 후에는 시스템 클럭이 예약 된 작업이 단지 사육사 클러스터 노드가 아닌 노드간에 동기화되어야하므로 안전한 솔루션이 아닐 수도 있습니다. 작업이 실행되고있는 노드가 GC 일시 중지 및 기타 이유로 과부하가 걸릴 수 있고 시계가 동기화되지 않을 가능성이 있기 때문에 안전하지 않다는 말입니다. 하지만 다시 이것은 분산 시스템의 표준 문제라고 생각합니다.
각 옵션에 대한 이해가 정확한지 조언 해주세요. 또는이 문제를 해결하기 위해 나열된 옵션보다 나은 접근 방법이있을 수 있습니다.
FYI - Curator/ZooKeeper 용 분산 작업 스케줄러를 작성했습니다. https://github.com/NirmataOSS/workflow – Randgalt