高吞吐高并发 Java NIO 服务的架构(NIO 架构及应用之一)
成功的应用在了各种分布式、即时通信和中间件 系统中。证明了基于 构建的通
信基础,是一种高效,且扩展性很强的通信架构。
基于 模式的高可扩展性架构这个架构的基本思路在“基于高可用性 服务器架构”
( !"#""#$"
)中有了清晰的论述。经过几年实际运营的经验,这种架构的灵活性得到了很好的验证。我们注
意几点,
,一个小的线程池负责 # 事件。
,注册事件,即操作 #" 时,要使用一个同步锁(即 % &!"'""
(#' 一文中的 ! 对象),即对同一个 #" 的操作是互斥的。
,这个小的线程池不处理逻辑业务,大小可以是 $!$)*""+###)*,,
即你系统有效 -+. 个数,。这是因为我们假设有一个线程专门处理 事件,
而其他线程处理 / 操作。
0,用另一个单独的线程池处理逻辑业务
1
在淘宝网团队博客上分析 架构的时候也谈到了这个思路,我决定说的比较好。这里引用一
段:
1
$$$#0写道
提供了 与 ()*两种模式处理这些逻辑,其中 主要通过一个 ('' 线程处理等
待链接的接入,若干个 234 线程)从 /5 线程池中挑选一个赋给 -" 实例,因为
-" 实例持有真正的 网络对象*接过 ('' 线程递交过来的 -&%46 进行数据读写并且
触发相应事件传递给 " 进行数据处理,而 ()*方式服务器端虽然还是通过一个 (''
线程来处理等待链接的接入,但是客户端是由主线程直接 7另外写数据 -' 两端都是直接主
线程写,而数据读操作是通过一个 234线程 (6-3 方式读取)一直等待,直到读到数据,
除非 " 关闭*。
网络动作归结到最简单就是服务器端 888/7客户端 88/7一般
或者 后会有多次 、/。这种特性导致,7 与 7/ 的线程分离,
与 、/ 线程分离,这样做的好处就是无论是服务器端还是客户端吞吐量将有效增大,
以便充分利用机器的处理能力,而不是卡在网络连接上,不过一旦机器处理能力充分利用后,这
种方式反而可能会因为过于频繁的线程切换导致性能损失而得不偿失,并且这种处理模型复杂度
比较高。
1
那么如果是我们自己开发基于 实现高效和高可扩展服务,还有哪些构架方面的问题需要考虑
呢?
构架中比较需要经验和比较复杂的主要是 点:7)是基于提高的性能的线程池设计;)基
于网络通讯量的通讯完整性校验的构架。
1. 基于提高的性能的线程池设计
既然有一个单独处理逻辑业务的线程池,这个线程池的大小应该由你的业务来决定。对于高效服
务器来说,这个线程池大小会对你的服务性能产生很大的影响。设置多少合适呢?
评论6