netty를 사용하는 서버 푸시 설계 netty에 대한 두 번째 질문에서

Question

. 우리는 이제 막 시작하고 있습니다. 또한 우리는 HTTP와 긴 폴링 HTTP 스트리밍을 사용해야하는 디자인을 가지고 있습니다. 연결이 열린 5k - 50k 연결된 사용자를 예상하고 있습니다. 우리는 바람둥이가 다루지 않을 것이라는 것을 알고 있습니다. 그래서 우리는 그 일을 성취하기 위해 그물을 살펴 봅니다.

디자인은 간단해야하지만 우리는 웹 소켓을 사용할 수 없습니다 (우리는 websocket/stomp 지원으로 netty 위에 hornetQ를 사용하고 싶습니다). 그러나 우리는 할 수 없습니다.

기본적으로 연결된 클라이언트에서 서버 푸시 이벤트 (JS SSE를 사용하는 경우도 있음)가 있습니다.

클라이언트는

그래서 우리는 이벤트를 생성하는 서버 측 프로세스를해야합니다 (그러나, JMS의 큐와 같은 훨씬 더 간단) URL을 기반으로 엔드 포인트에 가입하고 (우리가 관심있는 채널을 통지한다 이것에 간단한 관찰자 패턴을 사용하고있다).

그래서 채널은 해당 프로세스에 가입 한 다음 이벤트를 수신합니다.

오늘의 나의 질문은 우리가 사용한 디자인 접근 방식이 netty 아키텍처를 고려한 올바른 방법인지 확인하는 것입니다.

public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception { 
    service.subscribe(this); 
    this.context = ctx; 
    ctx.sendUpstream(e); 
} 

//this method gets called by the service when a server event happens 
public void onUpdate(String message) { 
    ChannelBuffer buffer = Channels.buffer(message.getBytes().length()); 
    buffer.writeBytes(message.getBytes()); 
    ChannelFuture future = Channels.future(this.context.getChannel()); 
    future.addListener(ChannelFutureListener.CLOSE); 
    Channels.write(this.context,future,buffer); 
} 

감사

Answer 1

괜찮아 보이지만 많은 거기 아니다. 긴 폴 시작 및 가능한 후속 시간 초과는 어떻게 처리합니까? (아니면 당신은 그걸 잘 알고 있습니다 ..... 이것은 스페인의 재판이 아닙니다.)

"URL 대기열"의 숫자와 인기도에 따라 고려해야 할 것이 하나 있습니다. ChannelGroup은 해당 URL 대기열에 가입 한 모든 채널의 컨테이너입니다. 그렇게하면 그룹에 메시지를 쓸 수 있습니다. 또한 채널이 닫히면 그룹에서 꺼내기 때문에 코드 간소화가 이루어집니다.

또한 HTTP 스트리밍을 고려 했습니까? 웹 소켓만큼 좋지는 않지만 긴 폴링보다 낫다.

모든 구현이 완벽하다는 것을 110 % 확신하지는 않지만 긴 폴링, 웹 소켓 및 http 스트리밍을 위해 Netty를 사용하는 JSON 푸시를 나타내는 test project을 함께 사용했습니다. 선택하는 푸시 유형에 적응하는 자바 스크립트 클라이언트도 있습니다. 유용 할 것입니다. (그리고 그것에 대한 피드백을 얻게되어 기쁩니다 ....)