1

在我关于netty的第二个问题中。我们才刚刚开始。我们有一个设计，我们需要使用带有长轮询HTTP 流的 HTTP。我们估计有 5k - 50k 连接用户打开连接。我们知道 tomcat 不会处理，所以我们查看 netty 来完成任务。

设计应该足够简单，但我们不能使用 websockets（我们希望在 netty 之上使用 hornetQ 并支持 websocket/stomp）但我们不能。

所以基本上我们将在连接的客户端中有服务器推送事件（我们甚至可以使用 JS SSE 来做到这一点）。

客户端将根据 url 订阅端点（就像 JMS 上的队列，不过要简单得多）

所以我们将在服务器端有一个进程来生成事件并通知感兴趣的通道（我们为此使用了一个简单的观察者模式）。

因此，频道订阅了这些进程，然后从它们接收事件。

我今天在这里的问题是看看我们使用的设计方法是否考虑到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);
}

问候

4

1 回答 1

4

看起来还可以，但那里没有太多东西。您如何处理长轮询启动和可能的后续超时？（或者也许你对此完全满意......这不是西班牙宗教裁判所）

根据“ URL 队列”的数量和受欢迎程度，您可能会考虑的一件事是使用ChannelGroup作为订阅该 url 队列的所有频道的容器。这样，您就可以将消息写入组。另外，当通道关闭时，它们将从组中弹出，因此那里有一些代码简化。

另外，您是否考虑过 HTTP 流式传输？在我看来，不如 websockets 好，但比长轮询好。

我不是 110% 确信所有的实现都是完美的，但我已经整理了一个测试项目，演示了使用 netty 进行长轮询、websockets 和 http 流的 JSON 推送。还有一个 javascript 客户端可以适应您选择的推送类型。您可能会发现它很有用（我很高兴收到任何反馈......）

于 2012-05-03T20:59:37.453 回答