构建可伸缩系统 Scala vs Java
2014-03-05 00:05
288 查看
这是Netty 4系列教程的一部分,主要介绍了Netty
4中使用的新线程模型以及如何解决在Netty3线程模型中出现的问题。
以channel为例,简单来说:
不考虑事件的传输和类型,所有的upstream事件(例如inboud)必须由处理channel I/O的线程触发。
所有的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
4中使用的新线程模型以及如何解决在Netty3线程模型中出现的问题。
以channel为例,简单来说:
不考虑事件的传输和类型,所有的upstream事件(例如inboud)必须由处理channel I/O的线程触发。
所有的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
相关文章推荐
- 构建高可用和弹性伸缩的KV存储系统
- 【Scala-ML】如何利用Scala构建并行机器学习系统
- 《分布式JAVA应用 基础与实践》 第七章 构建可伸缩的系统
- SBuild 0.1.5 发布,基于 Scala 的构建系统
- SBuild 0.2.0 发布,基于 Scala 的构建系统
- 使用jenkins、docker、consul、nginx搭建支持自动化构建部署以及弹性伸缩的集群系统详细教程
- [转]高性能可伸缩系统构建的简要思想
- 基于Raft构建弹性伸缩的存储系统的一些实践
- 《分布式JAVA应用 基础与实践》 第七章 构建可伸缩的系统
- 《分布式JAVA应用 基础与实践》 第七章 构建可伸缩的系统
- SBuild 0.3.0 发布,基于 Scala 的构建系统
- 构建可伸缩的系统笔记
- MVC3+EF4.1 构建高性能可伸缩的应用系统
- 构建高可用和弹性伸缩的KV存储系统
- SBuild 0.1.4 发布,基于 Scala 的构建系统
- 【数据应用】构建高可用和弹性伸缩的KV存储系统
- 书摘-构建高可用性和可伸缩系统
- 《分布式JAVA应用 基础与实践》 第七章 构建可伸缩的系统
- 基于Raft构建弹性伸缩的存储系统的一些实践
- 构建高可用可伸缩系统设计的一些方法论