构建可伸缩系统 Scala vs Java

这是Netty 4系列教程的一部分，主要介绍了Netty 4中使用的新线程模型以及如何解决在Netty3线程模型中出现的问题。

以channel为例，简单来说：

1. 不考虑事件的传输和类型，所有的upstream事件（例如inboud）必须由处理channel I/O的线程触发。
2. 所有的downstream（例如outbound）事件是可以由任意类型的线程触发，例如I/O线程和非I/O线程。然而，downstream事件的触发会带来一个副作用：在同一个I/O线程中，upstream事件也会被触发（例如，如果Channel.close()必须在I/O线程中触发channelDisconnecte、channelUnbound和channelClosed事件）。

目前的问题（UGLY-导致upstream处理存在竞争，BAD-不会导致竞争但是违反常规的线程模型）：

• UGLY：upstream事件触发之后会导致调用线程触发downstream事件。
• UGLY：本地传输总是使用调用线程触发一个事件。
• BAD：channelOpen是由调用ChannelFactory.newChannel()的线程触发的，这个线程不是I/O线程。这样不好，但是当关闭channel的时候不容易限制并发的活跃channel。如果在I/O线程中完成这个操作就不会有这种效果了。
• BAD：在客户端运行一个channel需要2个I/O线程。一个用于创建连接，另外一个处理实际的I/O操作。

改进措施：

• 将客户端boss、服务器端boss和NioWorker合并到一个通用的I/O线程中，由这个线程执行所有的I/O操作。实现细节：
  • 我们解决了客户端中的channel问题，因为线程在创建连接之后能够继续执行读写操作。
  • 我们解决了服务器监听多少个端口，Netty就会创建相同数量线程的问题。
  • 共享一个NioWorker 池更容易了，而且channel和worker映射更灵活了。
  • 需要研究一个抽象的I/O线程，这样所有的传输（socket、datagram、SCTP……）都能扩展它。目前socket、datagram和SCTP之间有太多的重复实现。
• 如果调用线程不是I/O线程，Netty会延迟然后在I/O线程中触发一个upstream事件。随着这个更改，允许用户调用ChannelPipleline和ChannelHandlerContext中的sendUpstreamLater()延迟到I/O线程中触发upstream事件。
  • 然而，只有当前运行线程是非I/O线程才能使用sendUpstreamLater()，这种限制是通过OMATPE和MATPE的接口标识起作用的，所以用户需要判断(例如，决定是调用sendUpstream()还是sendUpstreamLater()方法）。
• ChannelFactory.newChannel()不能立刻触发一个事件。newChannel()必须等待到I/O线程通知channel已经被注册到I/O线程，在将新的channel返回给调用者之前才能触发事件。
• 重写本地传输。

疑问：

• 我们能在v3实现这些修改，并且保证向下兼容吗？在v4中会不会更容易实现？在一个处理器中处理所有的I/O请求，充分利用了ChannelFuture的全异步用户应用不会受到当前有缺陷的线程模型的影响，这也意味着用户可以按照某种方式解决这个问题，一直在v4上做更新比同时在2个分支上做修改更好。

答案：

• 我认为如果需要做很多工作来将新修改移植到v3，还不如直接在v3中忽略这些修改. 或许我们能够找到一些更“容易”的方式来帮助我们解决v3中调用Channel.close()导致的竞争问题，这也是最受用户关心的事情。(normanmaurer)

 

英文原文：Thread Model in Netty 4，编译：ImportNew - 刘海波

译文链接：http://www.importnew.com/2913.html