2012-11-14 2 views
4

특정 이벤트 처리 및 데이터 생성을 기반으로하는 시스템을 개발하려고합니다. 각 이벤트에는 여러 필드가 포함되며 각 리스너는 일부 필드를 처리합니다. 나는 이벤트 생성 클래스 내 마음Java 이벤트 처리 디자인

  1. 에서 다음 두 가지 방법, 내가 예를 들어, 각 이벤트의 특정 필드의 특정 값에 대해 듣고, 여러 이벤트 리스너를 등록합니다 있습니다

    public class MicroListener implements Listener { 
    
    public void processEvent(Event e){ 
        if(e.getName().equals(registeredName)) { ... } 
    } 
    

처리가 개체 자체 내에서 수행되고 이벤트의 중앙 처리가 없으므로 각 개체가 정보를 처리 할 수 ​​있으므로 유혹입니다. 단점은, 치명적일 수있는 사실은 각 이벤트 (몇 십만 개 중)가 모든 청취자에게 브로드 캐스팅되어야한다는 사실입니다. 단, 극소수의 부분 만 실제로 청취 할 수 있습니다. 아마

  1. ... 모든 이벤트에 듣고 행동하는 중앙 집중화 된 리스너를, 장기적으로 큰 성능 저하를 생성하고, 예를 들어, 해당 이벤트 프로세서에 처리를 위임합니다 :

    public class CentralListener implements Listener { 
    
        Map<String, Processor> processorsByName; 
    
        public void processEvent(Event e){ 
         processorsByName.get(e.getName()).process(e); 
        } 
    } 
    

이 속도는 빠르지 만 이벤트의 다른 부분에 대해서는 별도의지도 또는 프로세서 모음이 필요합니다. 이벤트 ID 등을 검사하는 프로세서. 이것은 접근법 1의 경우는 아니며 단순히 다른 수신기 집합을 생성하여 이벤트 생성 클래스에 등록하기 만하면됩니다.

여러분은이 중 어떤 것에 대해 어떻게 생각합니까? 그들은 이해가됩니까, 아니면 전혀 달라 지겠습니까?

답변

3

이것은 일반적인 디자인 결정이며 모든 (또는 대부분의) 경우에 대해 올바른 일반적인 대답은 없다고 생각합니다. 두 가지 접근 방식에서 다양한 트레이드 오프를 나열 할 수 있지만 분명합니다. 높은 수준에서 가능한 성능 영향을 고려하기 전에 개념 모델에 가장 잘 어울리는 디자인이 무엇이든 (그리고 관계없는 클래스의 엉망을 만들지는 않습니다) 호감을 가졌습니다.

성능이 최대 관심사라면 정수 이벤트 ID를 전환하는 대용량 스위치/사례 블록을 사용하는 중앙 집중식 컨트롤러가 가장 빠를 것입니다. ... 그리고 시간이 지남에 따라 최소한의 유연성/유지 보수가 가능합니다.

Guava project's EventBus을 검토해보십시오. 주석을 사용하여 이벤트 리스너를 등록하고이 유형의 이벤트 브로드 캐스팅/구독에 매우 깨끗한 API를 제공합니다. 이벤트 등록자는 메소드 서명에서 선언 한 이벤트 유형에 따라 통지됩니다. 꽤 매끄럽고 보일러 판을 많이 절약합니다. 수천 개의 이벤트 유형으로 얼마나 확장 될지 모르지만 일부 유사한 라이브러리와는 달리 이벤트 버스는 글로벌하지 않습니다. 다른 이벤트 버스 인스턴스를 작성하여 이벤트 처리를 구분할 수 있습니다.

0

당신이 다소 크고 (잠재적으로) 복잡한 것의 시작 부분에있는 것처럼 들립니다. 아마도 당신이 언급 한 두 가지 이상의 명령형 접근 방식을 사용하기 전에 이벤트 기반 프로그래밍에 대해 자세히 살펴볼 것입니다. 아이디어는 리스너를 사용하는 것과 거의 동일하며 비동기식으로 만 구현되므로 이벤트 리스너는 행동 요청을받을 때만 작동하는 자체 스레드가 될 수 있습니다.

여기에 해당하는지는 잘 모르겠지만 다른 리스너로 전파해야하는 다른 이벤트 유형이 있다고 가정 해 보겠습니다. 옵서버를 하나의 거대한 힙에 저장하는 대신 관찰자가 등록 할 수있는 각 이벤트 유형에 대한 청취자를 만들지 않겠습니까? 이벤트를 생성하는 핵심 컴포넌트가있는 경우 리스너에서 이벤트를 보내면 다시 관찰자에게 전송됩니다.

내 눈에는 주요 책임은 책임을 (청취자에게) 돌보아주기 전에 위임받는 것입니다. 프로그래머를 도울 수있는 큰 환경에서 성능 병목 현상을 방지합니다. 나는 이것을 reactor pattern라고도합니다.

영감을 얻으려면 akka framework을 사용해보십시오. 효율적인 분산 이벤트 프로그래밍을 위해 설계되었습니다.