세 부분으로 구성된 응용 프로그램 디자인을 연구하고 있습니다.
- 특정 이벤트 (파일 생성, 외부 요청 등)를 감시하는 단일 스레드
- 이러한 이벤트를 처리하여 응답하는 N 작업자 스레드 (각 작업자 프로세스 및 단일 이벤트 소비 및 처리에 시간이 걸릴 수 있음)
- 해당 스레드를 관리하고 오류 처리 (스레드 재시작, 결과 로깅)를 수행하는 컨트롤러
이것은 매우 기본적이고 구현하기 어렵지는 않지만, "올바른"방법이 무엇인지 궁금합니다 (이 구체적인 경우 Java에서는 더 높은 추상화 응답도 감사합니다). 두 가지 전략이 떠 오릅니다.
관찰 / 관찰 가능 : 컨트롤러가 관찰 스레드를 관찰합니다. 이벤트가 발생하면 컨트롤러에 알림이 전달되고 재사용 가능한 캐시 된 스레드 풀에서 사용 가능한 스레드에 새 작업을 할당 할 수 있습니다 (또는 모든 스레드가 현재 사용중인 경우 FIFO 대기열에서 작업을 캐시에 저장). 작업자 스레드는 Callable을 구현하고 결과 (또는 부울 값)와 함께 성공을 반환하거나 오류와 함께 반환합니다.이 경우 컨트롤러는 수행 할 오류의 유형에 따라 수행 할 작업을 결정할 수 있습니다.
생산자 / 소비자 : 감시 스레드는 컨트롤러 (이벤트 큐)와 BlockingQueue를 공유하고 컨트롤러는 모든 작업자 (태스크 큐 및 결과 큐)와 두 개를 공유합니다. 이벤트의 경우 감시 스레드는 이벤트 큐에 작업 개체를 넣습니다. 컨트롤러는 이벤트 대기열에서 새 작업을 가져 와서 검토 한 후 작업 대기열에 넣습니다. 각 작업자는 새 작업을 기다렸다가 작업 대기열 (처음으로 먼저 제공되고 대기열 자체에서 관리)에서 작업을 가져와 소비하여 결과 또는 오류를 결과 대기열에 다시 넣습니다. 마지막으로, 컨트롤러는 결과 대기열에서 결과를 검색하고 오류 발생시 단계를 수행 할 수 있습니다.
두 접근 방식의 최종 결과는 비슷하지만 각각 약간의 차이가 있습니다.
옵저버를 사용하면 스레드를 직접 제어 할 수 있으며 각 작업은 새로 생성 된 특정 작업자에 의해 이루어집니다. 스레드 생성을위한 오버 헤드는 더 높을 수 있지만 캐시 된 스레드 풀 덕분에 그리 많지는 않습니다. 반면, Observer 패턴은 다중이 아닌 단일 Observer로 축소되어 정확히 설계된 것이 아닙니다.
대기열 전략은 확장하기가 더 쉽습니다. 예를 들어 하나 대신 여러 생산자를 추가하는 것이 간단하고 변경이 필요하지 않습니다. 단점은 전혀 작업을 수행하지 않아도 모든 스레드가 무기한으로 실행되며 오류 / 결과 처리가 첫 번째 솔루션처럼 우아하지 않다는 것입니다.
이 상황에서 가장 적합한 접근법은 무엇이며 왜 그런가? 대부분의 예제는 Observer 케이스에서 새로운 값으로 많은 창을 업데이트하거나 여러 소비자 및 생산자와 처리하는 것과 같이 명확한 사례 만 다루기 때문에 온라인 에서이 질문에 대한 답변을 찾기가 어렵다는 것을 알았습니다. 모든 의견을 높이 평가합니다.