原生NIO存在的问题(Netty要解决的问题)
- 虽然
JAVA NIO
和JAVA AIO
框架提供了多路复用IO/异步IO的支持,但是并没有提供给上层“信息格式”的良好封装。JAVA NIO 的 API
使用麻烦,需要熟练掌握ByteBuffer
、Channel
、Selector
等 , 所以用这些API实现一款真正的网络应用则并非易事 JAVA NIO
和JAVA AIO
并没有提供断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流等的处理,这些都需要开发者自己来补齐相关的工作。JDK NIO
的Bug
:例如臭名昭著的Epoll Bug
,它会导致Selector
空轮询,最终导致CPU100%
。直到JDK1.7
版本该问题仍旧存在,没有被根本解决。AIO
在实践中,并没有比NIO
更好。AIO
在不同的平台有不同的实现,windows系统下使用的是一种异步IO技术:IOCP
;Linux下由于没有这种异步 IO 技术,所以使用的是epoll
对异步 IO 进行模拟。所以 AIO 在 Linux 下的性能并不理想。AIO 也没有提供对 UDP 的支持。- 综上,在实际的大型互联网项目中,Java 原生的 API 应用并不广泛,取而代之的是一款第三方Java 框架,这就是
Netty
。
Netty的作者
Netty创始人Trustin Lee
-
Netty的创始人是韩国人Trustin Lee,80年出生,8岁起在MSX迷你计算机上编写BASIC程序,爱好游戏编程以及使用汇编、C和C++解决编程问题,1998年获得韩国信息奥林匹克竞赛铜牌。
-
就读于韩国Yonsei大学计算机系期间,曾为多家公司编写高性能网络应用以及少量的web程序,毕业后,就职于Arreo通讯公司,该公司为韩国最大的移动短信提供商之一。
-
他还是另一个著名网络应用框架 Mina 的重要贡献者
4. Trustin Lee大神的博客和github
他的个人博客:https://t.motd.kr/
他的Github:https://github.com/trustin
Netty另外一个Leader
- Netty项目另外一个leader是德国人Norman Maurer(之前在Redhat,全职开发Netty),也是《Netty in Action》的作者,目前是苹果公司高级工程师。
- Norman maurer大神的博客和github
他的个人博客:http://normanmaurer.me/
他的Github:https://github.com/normanmaurer
Netty的基本介绍
Netty官方网址:https://netty.io/
Netty的api地址:https://netty.io/4.1/api/index.html
Netty is an asynchronous event-driven network application framework
for rapid development of maintainable high performance protocol servers & clients.
Netty 是一个异步的、基于事件驱动的网络应用框架,用于快速开发可维护、高性能的网络服务器和客户端
Netty is an NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.
Netty是一个基于NIO的客户端-服务器框架,可以快速轻松地开发网络应用程序,如基于协议服务器和客户端应用程序。它极大地简化和优化了网络编程,如TCP和UDP套接字服务器程序的开发。
‘Quick and easy’ doesn’t mean that a resulting application will suffer from a maintainability or a performance issue. Netty has been designed carefully with the experiences earned from the implementation of a lot of protocols such as FTP, SMTP, HTTP, and various binary and text-based legacy protocols. As a result, Netty has succeeded to find a way to achieve ease of development, performance, stability, and flexibility without a compromise.
“快速简单”并不意味着生成的应用程序会受到可维护性或性能问题的影响。Netty经过精心设计,从实现许多协议(如FTP、SMTP、HTTP)以及各种二进制和基于文本的遗留协议中获得了经验。因此,Netty成功地找到了一种在不妥协的情况下实现易于开发、性能、稳定性和灵活性的方法。
Features
Design
Unified API for various transport types - blocking and non-blocking socket
为各种网络传输模型,提供统一的api , 比如:阻塞 和 非阻塞的套接字传输模型
Based on a flexible and extensible event model which allows clear separation of concerns
基于灵活和可扩展的事件模型 , 可以清楚的分离关注点(指事件触发的关注点)
Highly customizable thread model - single thread, one or more thread pools such as SEDA
高度的可定制化线程模型 , 支持单线程 , 多线程 比如 SEDA 模型
True connectionless datagram socket support (since 3.1)
对于无连接的数据报套接字udp确实是从 3.1 开始的
Ease of use
Well-documented Javadoc, user guide and examples
No additional dependencies, JDK 5 (Netty 3.x) or 6 (Netty 4.x) is enough
Note: Some components such as HTTP/2 might have more requirements. Please refer to the Requirements page for more information.
丰富的文档javadoc , 用户指南和示例
没有额外的依赖 , JDK 5(Netty 3.x)或6(Netty 4.x)就足够了
注意:有些组件(如HTTP/2)可能有更多的要求。有关详细信息,请参阅“要求”页面。
Performance
Better throughput, lower latency
Less resource consumption
Minimized unnecessary memory copy
更好的吞吐量 , 低延迟
减少资源消耗
最小化不必要的内存复制
Security
Complete SSL/TLS and StartTLS support
完全支持 SSL/TLS 和 StartTLS
Community
Release early, release often
The author has been writing similar frameworks since 2003 and he still finds your feed back precious!
提前发布 , 常发布
作者自2003年以来一直在写类似的框架,他仍然觉得你的反馈很珍贵!
从上述的架构图可以看出,Netty 主要由三大块组成:
-
核心组件
-
核心组件包括:零拷贝和字节缓冲区 , 通用的通信API , 可扩展的事件模型
- 零拷贝和字节缓冲区
Netty 使用了区别于Java ByteBuffer
的新的缓冲类型ByteBuf
,ByteBuf
提供了丰富的特性 , 并提供内存映射 和 零拷贝机制 - 通用的通信API
Netty 的通信API都被抽象到Channel
里,以统一的异步I/O
编程接口来满足所有点对点的通信操作。 - 可扩展的事件模型
Netty 是基于异步事件驱动的,该框架体现为所有的I/O
操作都是异步的,调用者并不能立即获得结果,而是通过事件监听机制
,用户可以方便的主动获取或者通过通知机制获得I/O
操作的结果。Netty 将所有的事件按照它们与入站或出站数据流的相关性进行了分类。
可能由入站数据或者相关的状态更改而触发的事件包括以下几项
:- 连接已被激活或连接失活
- 数据读取
- 用户事件
- 错误事件
出站事件是未来将会触发的某个动作的操作结果,包括以下动作
: - 打开或者关闭到远程节点的连接
- 将数据写到或者冲刷到socket套接字中
每个事件都可以被分发到
ChannelHandler
类中的某个用户实现的方法。 - 零拷贝和字节缓冲区
-
-
传输服务
Netty 内置了一些开箱即用的传输服务。因为并不是它们所有的传输都支持每一种协议,所以必须选择一个和应用程序所使用的协议相兼容的传输。以下是Netty提供的所有的传输。- NIO
io.netty.channel.socket.nio
包用于支持NIO。该包下面的实现是使用java.nio.channels
包作为基础(基于选择器的方式)。 - Epoll
io.netty.channel.epoll
包用于支持由 JNI 驱动的 epoll 和 非阻塞 IO。
需要注意的是,这个epoll
传输只能在 Linux 上获得支持。epoll
同时提供多种特性,如: SO_REUSEPORT 等,比 NIO传输更快,而且是完全非阻塞的。 - OIO
io.netty.channel.socket.oio
包用于支持使用java.net
包作为基础的阻塞I/O
。 - 本地
io.netty.channel.local
包用于支持在 VM 内部通过管道进行通信的本地传输。 - 内嵌
io.netty.channel.embedded
包作为内嵌传输,允许使用ChannelHandler
而又不需要一个真正的基于网络的传输。
- NIO
-
支持的协议
Netty 支持丰富的网络协议,如TCP
、UDP
、HTTP
、HTTP/2
、WebSocket
、SSL/TLS
等,这些协议实现开箱即用,因此,Netty 开发者能够在不失灵活的前提下来实现开发的简易性、高性能和稳定性。
异步和事件驱动
Netty 是异步事件驱动的框架,该框架体现为所有的I/O
操作都是异步的,所有的I/O
调用会立即返回,并不保证调用成功与否,但是调用会返回ChannelFuture
。Netty 会通过 ChannelFuture
通知调用是成功了还是失败了,抑或是取消了。
同时,Netty 是基于事件驱动的,调用者并不能立即获得结果,而是通过事件监听机制,用户可以方便地主动获取或者通过通知机制获得I/O
操作的结果。
当Future
对象刚刚创建时,处于非完成状态,调用者可以通过返回的ChannelFuture
来获取操作执行的状态,再通过注册监听函数来执行完成后的操作,常见有如下操作:
- 通过
isDone
方法来判断当前操作是否完成。 - 通过
isSuccess
方法来判断已完成的当前操作是否成功。 - 通过
getCause
方法来获取已完成的当前操作失败的原因。 - 通过
isCancelled
方法来判断已完成的当前操作是否被取消。 - 通过
addListener
方法来注册监听器,当操作已完成(isDone
方法返回完成),将会通知指定的监听器;如果future
对象已完成,则理解通知指定的监听器。
例如:下面的代码中绑定端口是异步操作,当绑定操作处理完,将会调用相应的监听器处理逻辑。
serverBootstrap.bind(port).addListener(future -> {if(future.isSuccess()){System.out.println("端口绑定成功!");}else {System.out.println("端口绑定失败!");}
});
Netty的应用场景
互联网行业
- 互联网行业:在分布式系统中,各个节点之间需要远程服务调用,高性能的
RPC
框架必不可少,Netty
被这些RPC框架所使用 - 典型的应用有:阿里分布式服务框架
Dubbo
的RPC
框 架使用Dubbo
协议进行节点间通信,Dubbo
协议默认使用Netty
作为基础通信组件,用于实现各进程节点之间的内部通信。 - 在Java领域Netty被广泛的应用,Tomcat,Dubbo,RocketMQ,Zookeeper,ElasticSearch等等这些中间件的网络通讯框架都是Netty实现的。
游戏行业
- 无论是手游服务端还是大型的网络游戏,
Java
语言得到了越来越广泛的应用。 Netty
作为高性能的基础通信组件,提供了TCP/UDP
和HTTP
协议栈,方便定制和开发私有协议栈- 地图服务器之间可以方便的通过
Netty
进行高性能的通信。
大数据领域
- 经典的
Hadoop
的高性能通信和序列化组件Avro
的RPC
框架,默认采用Netty
进行跨节点通信。
Netty版本说明
Netty
版本分为Netty 3.x
和Netty 4.x
、Netty 5.x
- 因为
Netty 5
出现重大bug
,已经被官网废弃了,目前推荐使用的是Netty 4.x
的稳定版本 - 目前在官网可下载的版本
Netty 3.x
、Netty 4.0.x
和Netty 4.1.x
参考文档:https://www.cnblogs.com/jiangwang001/p/15101684.html