Netty:一个非阻塞的客户端/服务器框架

Netty:一个非阻塞的客户端/服务器框架

作者:chszs,转载需注明。博客主页:http://blog.csdn.net/chszs

Netty是一个异步事件驱动的网络应用框架,为Java网络应用的开发带来了一些新活力。Netty由协议服务器和客户端所组成,可用于快速开发可维护的高性能软件。Netty应用框架及其工具简化了网络编程,而且由Netty社区进行维护。

Netty还被归类为NIO客户端/服务器框架,用它能够快速、简易地开发网络应用,使得TCP和UDP套接字服务器的网络编程得以简化和更加合理。

内建的HTTP协议支持WebSocket,允许框架运行在Servlet容器内。新版的Netty同时支持非阻塞I/O和阻塞I/O通信。

Netty的特性:

1、传输服务包括:套接字和数据报、HTTP通道、虚拟机内部管道

2、协议支持以下扩展:HTTP、Web Socket、Google Protocol Buffer、SSL-StartTLS、大文件传输、RTSP、Zlib或gzip压缩、二进制协议、其它遗留的文本格式

3、核心:可扩展的事件模型、统一通信API、零拷贝能力的富字节缓冲

Netty设计:

Netty在设计上针对多种传输类型,集成了一套统一的API、阻塞和非阻塞的套接字。Netty的事件模型是可扩展的,可以把关注点进行明确隔离。Netty的线程模型提供了在单线程或类SEDA这样的线程池之间选择的灵活性,而且线程是高可自定义的,对数据报的支持实现了真正的无连接通信,Netty的管道抽象与安全线程、动态可变性相结合,使得框架得到有力支撑。

注:SEDA,即Staged Event Driven Architecture,阶段化的事件驱动架构。SEDA的思路是将原先由一个线程完成的任务,分割为相对独立的多个阶段。每个阶段由专用的一组线程负责执行,阶段之间用过队列交互。采用SEDA方式,只有在并发量提高到一定程度,并发成为系统瓶颈时才能体现价值。就单个操作而言,由于队列的传递,其延迟一定是有所上升的。

可以参考这篇论文《SEDA: an Architecture for Well-Conditioned, Scalable Internet Services

SEDA是加州大学伯克利分校研究的一套优秀的高性能互联网服务器架构模型,其设计目标是:支持大规模并发处理、简化系统开发、支持处理监测、支持系统资源管理。

两种目前广泛使用的网络服务器架构模型:

1)多线程服务器(Threaded Server)

工作原理:对于每一个request,dispatcher都会为其创建并分配一个线程,该线程负责这个请求的处理。此方式又名为(Thread-per-request)。

优点:执行粒度是整个完整的处理流程,处理逻辑清晰,易于开发。
缺点:当随着处理请求的不断增加,会导致并发执行的线程数量太多。过多的线程数量会导致系统在线程调度和资源争用上的开销过大,从而引起系统性能急剧下降,导致系统处理能力下降。
改进措施:引入线程池(Bounded Thread Pools)
系统最多只能创建一定数量的线程。当所有线程都饱和运行时,新到达的处理请求只能等待,或者被抛弃。
缺点:执行粒度仍然是完整的处理流程,难以检测系统性能瓶颈的根源以及进行相应调整。

2)事件驱动并发处理(Event-Driven Concurrency)

将处理流程分割成多个步骤,每一个步骤都实现为一个有限状态机(FSM)。
工作原理:所有的处理请求会作为Event进入系统,由Scheduler负责传递给相应FSM。FSM的处理结果也以Event形式输出给Scheduler。新的Event会再次被Scheduler进行转发给下一个FSM,直至处理完成。

优点:
1、随着处理量的增加,系统负荷是以线形增长。当达到系统饱和处理能力后,系统的处理能力不会下降。
2、由于将各处理步骤独立实现,易于进行系统监测和调整。
缺点:
Scheduler的设计和实现过于复杂,针对于不同的应用和系统的逻辑变更需要不同的实现。

SEDA架构

(近似于Event-Driven Concurrency,但是没有其中的Scheduler)将每一个处理步骤独立为一个Stage。

Stage结构:
1)一个接受输入的Event Queue;
2)一个应用开发者编写的Event Handler;
3)一个Controller用于对执行过程进行控制。包括并发线程数量、批处理数量等等;
4)一个Thread Pool用于并发处理;
Stage的输入通过Event Queue获得。Stage的输出会以Event形式推送到其他Stage的Event Queue中。Stage之间的这种连接关系由应用开发人员指定。
带来的问题:Event Queue尽管减少了模块间的耦合性,但是会降低响应速度。

性能及有效性:

Netty不仅提供了良好的稳定性,还提供了更好的吞吐量和更低的延迟性能,把内存复制限制到最低需求上,零拷贝能力富字节缓冲特性使内核能够管理DMA复制。这减少了CPU和系统总线的负担,提升了框架的有效性。

可扩展性与集成:

Netty有可扩展能力,支持扩展到上千种连接类型,而且在维持有效性的同时没有性能瓶颈。这些连接的可靠性都非常高,而且不会失效。Netty易于扩展和构建。Netty还提供了灵活的集成性能,可以与很多环境比如Linux、Java、C#、C++、Python等环境集成。

安全:Netty提供了完整的SSL/TLS和StartTLS支持。

Netty官方提供了很多指南、文档以及JavaDoc和例子供开发者参考。

Netty目前的最新稳定版是4.0.23版。

下载地址: http://dl.bintray.com/netty/downloads/netty-4.0.23.Final.tar.bz2

时间: 2024-08-08 10:00:29

Netty:一个非阻塞的客户端/服务器框架的相关文章

使用OTP原理构建一个非阻塞的TCP服务器(转)

经测试可用! 原文地址:http://www.iucai.com/?paged=8 Erlang OTP设计原理已经被shiningray兄翻译透了.请参见.http://erlang.shiningray.cn/otp-design-principles/index.html 这里翻译了一篇余锋老大和lzy.je老大推荐的文章,闲话不说,奉上. 使用OTP原理构建一个非阻塞的TCP服务器 原文网址:(打不开的同学请自觉FQ) http://www.trapexit.org.nyud.net:8

实现一个非阻塞IO的服务器

先来实现一个简单的服务器,这个服务器简单的回送任何客户端的输入 EchoServer.java package server; import java.io.*; import java.net.*; import java.util.*; /** * This program implements a simple server that listens to port 8189 and echoes back all client input * @author zhangchen * */

使用OTP原则构建一个非阻塞的TCP服务器

http://erlangcentral.org/wiki/index.php/Building_a_Non-blocking_TCP_server_using_OTP_principles CONTENTS [hide] 1 Author 2 Overview 3 Server Design 4 Application and Supervisor behaviours 5 Listener Process 6 Client Socket Handling Process 7 Applicat

Select单进程非阻塞TCP echo服务器

1. select 描述 #include <sys/select.h> #include <sys/time.h> int select( int maxfdp1,   fd_set *readset,  fd_set *writeset,  fd_set *exceptset,  const struct timeval *timeout); 返回:正确:就绪描述符数目:超时: 0:出错: -1 参数说明: timeout: 内核等待指定描述符集合中的任意一个就绪的时间. st

SPWebServer:一个基于 SPServer 的 web 服务器框架

SPWebServer:一个基于 SPServer 的 web 服务器框架 博客分类: OpenSource项目 应用服务器框架Web网络应用多线程 看到这个题目,估计很多人会问:为什么要再实现一个 web 服务器? 这里有几个原因: 1.这是一个 web 服务器框架,不是一个完整的 web 服务器.也就是说 SPWebServer 提供的是一套 API 和类库,可以方便地集成到现有的应用程序中.可以称 SPWebServer 为 embedded web server . 2.有些时候,我们需

弹出一个非阻塞对话框

今天有个小需求, 程序要求执行一个检测操作, 如果检测失败的话则弹出信息并且关闭程序 由于检测代码是封装到一个独立进程里的, 所以直接使用TerminateProcess(GetCurrentProcess, 0);来关闭当前进程 可是在测试时却发现, 原本使用MessageBox来弹出消息却会阻塞结束进程的操作 一般我们在系统里弹出对话框都是调用Windows.MessageBox, 这个方法在一般情况下, 可以不阻塞本程序的操作(虽然在代码层面仍然是阻塞的) 大家可以用一个小例子试试 pro

linux下异步RPC的阶段性总结-非阻塞SOCKET客户端

尽可能使用非阻塞socket int flags, s;    flags = fcntl (fd, F_GETFL, 0);        if (flags == -1){            close(fd);          return -1;      }          flags |= O_NONBLOCK;        s = fcntl (fd, F_SETFL, flags);        if (s == -1){            close(fd); 

弹出一个非阻塞对话框(在程序关闭后 仍然显示对话框)

今天有个小需求, 程序要求执行一个检测操作, 如果检测失败的话则弹出信息并且关闭程序 由于检测代码是封装到一个独立进程里的, 所以直接使用TerminateProcess(GetCurrentProcess, 0);来关闭当前进程 可是在测试时却发现, 原本使用MessageBox来弹出消息却会阻塞结束进程的操作 一般我们在系统里弹出对话框都是调用Windows.MessageBox, 这个方法在一般情况下, 可以不阻塞本程序的操作(虽然在代码层面仍然是阻塞的) 大家可以用一个小例子试试 pro

使用 erlang OTP 模式编写非阻塞的 tcp 服务器(来自erlang wiki)

参考资料:http://erlangcentral.org/wiki/index.php/Building_a_Non-blocking_TCP_server_using_OTP_principles 服务器设计tcp_server_app下的根监控树使用one_for_one重启策略.两个子树应用,第一个是一个tcp套接字监听服务器,使用gen_server模式来实现,采用异步监听的客户端连接的模式.第二个是一个客户端应用,使用gen_fsm模式实现,使用标准SASL错误报告接口,记录客户端消