Netty的深入浅出--49.Scalable IO in Java的多线程版本分析(二)

多线程设计

*策略性的增加线程为的是可伸缩性,主要应用于多核处理器中

工作线程(对于我们的workGroup)

reactor应该能够快速的触发处理器

*处理器会减慢reactor的处理(原因:因为reactor将任务分发出给handler,因为是单线程,所以处理器被分发的任务变多的时候,就会拖慢reactor的处理)

因此卸去一些非IO的处理交给其他的线程处理

多个reactor线程

reactor线程能够进行IO的处理

分配负载到其他的reactor中

负载均衡,让CPU和IO速率进行匹配

工作线程:

*卸去非IO处理来提高速度

reactor线程

类似于POSA2 Proactor designs

*比起重新计算绑定过程到事件驱动形式更加简单

仍然应该是纯粹的非阻塞的计算

*足够的过程去处理负载

*但是很困难进行IO重叠处理

最好的操作是能够首先将读全部输入到一个buffer中

使用线程池能够进行调整和控制

通常线程的数量比客户端的数量要少

 还是多个客户端与reactor发起连接,我们可以看到它是通过一个线程池来处理请求的

查看线程池的处理方式,

协同任务

*Handoffs

每一个任务都能够被启用,触发或者调用下一个

它是很快的,但是很脆弱

Callbacks  :针对于每个处理器分配器

设置状态,attachment等

一种gof调停者模式

队列

例如:传递buffers在某些阶段

Futures

每一个任务都产生一个结果

在join或者wait/notify的上面实现协同阶段

 使用PoolExecutor

*一个和谐的工作线程池

*主要的方法是execute(Runnable r)

*Controls for:

任务队列的种类

线程的最大数量

线程的最小数量

“Warm”与 on-demand线程

保持存活的时间间隔直到线程死亡

*如果有必要的话,新的可以替换掉老的

饱和的策略:

*阻塞,去除,制作-运行等

多个reactor线程

*使用Reactor Pools

用于匹配CPU和IO的速率

静态的和动态的构建

*每一个都拥有自己的selector、线程、调度循环

主要的acceptor会分发(处理器)给其他的reactor;

 使用多Reactor

mainReactor理解成netty中的bossGroup(parentGroup)

subReactor理解成netty中的workGroup(childGroup)

 使用其他的NIO特性

*每个Reactor对应着多个selectors

将不同的处理器绑定到不同的IO事件。

需要一些同步来协调。

*文件传输

自动化的文件传输到网络或网络传输到文件的拷贝

*记忆映射文件

获取文件通过buffers

*Direct buffers

能够实现0拷贝传输

有些创建和结束

对于那些长连接它的效果是更好的

基于连接的扩展

*而不是单个服务请求

客户端连接

客户端发送一系列的信息和请求

客户端断开连接

例子:

数据库和事务的监控

 

对java的API进行一些说明:

 

猜你喜欢

转载自blog.csdn.net/qq_37909508/article/details/91355773