高性能Server---Reactor模型【转载】
原文连接：http://www.ivaneye.com/2016/07/23/iomodel.html
无处不在的C/S架构
在这个充斥着云的时代,咱们使用的软件能够说99%都是C/S架构的！html
- 你发邮件用的Outlook,Foxmail等
- 你看视频用的优酷，土豆等
- 你写文档用的Office365,googleDoc，Evernote等
- 你浏览网页用的IE,Chrome等(B/S是特殊的C/S)
- ……
C/S架构的软件带来的一个明显的好处就是：只要有网络，你能够在任何地方干同一件事。java
例如：你在家里使用Office365编写了文档。到了公司，只要打开编辑地址就能够看到在家里编写的文档，进行展现或者继续编辑。甚至在手机上进行阅读与编辑。再也不须要U盘拷来拷去了。react
C/S架构能够抽象为以下模型：git
- C就是Client(客户端),上面的B是Browser(浏览器)
- S就是Server(服务器)：服务器管理某种资源，而且经过操做这种资源来为它的客户端提供某种服务
C/S架构之因此可以流行的一个主要缘由就是网速的提升以及费用的下降，特别是无线网络速度的提升。试想在2G时代，你们最多就是看看文字网页，小说什么的。看图片，那简直就是奢侈！更别说看视频了！github
网速的提升，使得愈来愈多的人使用网络，例如：优酷，微信都是上亿用户量，更别说天猫双11的瞬间访问量了！这就对服务器有很高的要求！可以快速处理海量的用户请求！那服务器如何能快速的处理用户的请求呢？编程
高性能服务器
高性能服务器至少要知足以下几个需求：浏览器
- 效率高：既然是高性能，那处理客户端请求的效率固然要很高了
- 高可用：不能随便就挂掉了
- 编程简单：基于此服务器进行业务开发须要足够简单
- 可扩展：可方便的扩展功能
- 可伸缩：可简单的经过部署的方式进行容量的伸缩，也就是服务须要无状态
而知足如上需求的一个基础就是高性能的IO!安全
Socket
不管你是发邮件，浏览网页，仍是看视频～实际底层都是使用的TCP/IP，而TCP/IP的编程抽象就是Socket!服务器
我一直对Socket的中文翻译很困惑，我的以为是我所接触的技术名词翻译里最莫名其妙的，没有之一！微信
Socket中文翻译为”套接字”！什么鬼？在很长的时间里我都没法将其和网络编程关联上！后来专门找了一些资料，最后在知乎上找到了一个还算满意的答案(具体连接，请见文末的参考资料连接)！
Socket的原意是插口，想表达的意思是插口与插槽的关系！”send socket”插到”receive socket”里，创建了连接，而后就能够通讯了！
套接字的翻译，应该是参考了套接管(以下图)！从这个层面上来看，是有那么点意思！
套接字这个翻译已是标准了，不纠结这个了！
咱们看一下Socket之间创建连接及通讯的过程！实际上就是对TCP/IP链接与通讯过程的抽象:
- 服务端Socket会bind到指定的端口上，Listen客户端的”插入”
- 客户端Socket会Connect到服务端
- 当服务端Accept到客户端链接后
- 就能够进行发送与接收消息了
- 通讯完成后便可Close
对于IO来讲，咱们听得比较多的是:
- BIO:阻塞IO
- NIO:非阻塞IO
- 同步IO
- 异步IO
以及其组合:
- 同步阻塞IO
- 同步非阻塞IO
- 异步阻塞IO
- 异步非阻塞IO
那么什么是阻塞IO、非阻塞IO、同步IO、异步IO呢？
- 一个IO操做其实分红了两个步骤：发起IO请求和实际的IO操做
- 阻塞IO和非阻塞IO的区别在于第一步：发起IO请求是否会被阻塞，若是阻塞直到完成那么就是传统的阻塞IO;若是不阻塞，那么就是非阻塞IO
- 同步IO和异步IO的区别就在于第二个步骤是否阻塞，若是实际的IO读写阻塞请求进程，那么就是同步IO，所以阻塞IO、非阻塞IO、IO复用、信号驱动IO都是同步IO;若是不阻塞，而是操做系统帮你作完IO操做再将结果返回给你，那么就是异步IO
举个不太恰当的例子 ：好比你家网络断了，你打电话去中国电信报修！
- 你拨号—客户端链接服务器
- 电话通了—链接创建
- 你说：“我家网断了,帮我修下”—发送消息
- 说完你就在那里等，那么就是阻塞IO
- 若是正好你有事，你放下带电话，而后处理其余事情了，过一会你来问下，修好了没—那就是非阻塞IO
- 若是客服说：“立刻帮你处理，你稍等”—同步IO
- 若是客服说：“立刻帮你处理，好了通知你”，而后挂了电话—异步IO
本文只讨论BIO和NIO,AIO使用度没有前二者普及，暂不讨论！
下面从代码层面看看BIO与NIO的流程!
BIO
- 客户端代码
//Bind,Connect
Socket client = new Socket("127.0.0.1",7777);
//读写
PrintWriter pw = new PrintWriter(client.getOutputStream());
BufferedReader br=
new BufferedReader(new InputStreamReader(System.in));
pw.write(br.readLine());
//Close
pw.close();
br.close();
- 服务端代码
//Bind,Listen ServerSocket ss = new ServerSocket(7777); while (true) { //Accept socket = ss.accept(); //通常新建一个线程执行读写 BufferedReader br = new BufferedReader( new InputStreamReader(socket .getInputStream())); System.out.println("you input is : " + br.readLine()); }
模型图以下所示：上面的代码能够说是学习Java的Socket的入门级代码了
代码流程和前面的图能够一一对上
BIO优缺点
- 优势
- 模型简单
- 编码简单
- 缺点
- 性能瓶颈低
优缺点很明显。这里主要说下缺点：主要瓶颈在线程上。每一个链接都会创建一个线程。虽然线程消耗比进程小，可是一台机器实际上能创建的有效线程有限，以Java来讲，1.5之后，一个线程大体消耗1M内存！且随着线程数量的增长，CPU切换线程上下文的消耗也随之增长，在高过某个阀值后，继续增长线程，性能不增反降！而一样由于一个链接就新建一个线程，因此编码模型很简单！
就性能瓶颈这一点，就肯定了BIO并不适合进行高性能服务器的开发！像Tomcat这样的Web服务器，从7开始就从BIO改为了NIO，来提升服务器性能！
NIO
- NIO客户端代码(链接)
//获取socket通道 SocketChannel channel = SocketChannel.open(); channel.configureBlocking(false); //得到通道管理器 selector=Selector.open(); channel.connect(new InetSocketAddress(serverIp, port)); //为该通道注册SelectionKey.OP_CONNECT事件 channel.register(selector, SelectionKey.OP_CONNECT);
- NIO客户端代码(监听)
//选择注册过的io操做的事件(第一次为SelectionKey.OP_CONNECT)
selector.select();
while(SelectionKey key : selector.selectedKeys()){
if(key.isConnectable()){
SocketChannel channel=(SocketChannel)key.channel();
if(channel.isConnectionPending()){
channel.finishConnect();//若是正在链接，则完成链接
}
channel.register(selector, SelectionKey.OP_READ);
}else if(key.isReadable()){ //有可读数据事件。
SocketChannel channel = (SocketChannel)key.channel();
ByteBuffer buffer = ByteBuffer.allocate(10);
channel.read(buffer);
byte[] data = buffer.array();
String message = new String(data);
System.out.println("recevie message from server:, size:"
+ buffer.position() + " msg: " + message);
}
}
}
- 获取一个ServerSocket通道NIO服务端代码(链接)
ServerSocketChannel serverChannel = ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.socket().bind(new InetSocketAddress(port)); //获取通道管理器 selector = Selector.open(); //将通道管理器与通道绑定，并为该通道注册SelectionKey.OP_ACCEPT事件， serverChannel.register(selector, SelectionKey.OP_ACCEPT);
|
|
- NIO服务端代码(监听)
while(true){
//当有注册的事件到达时，方法返回，不然阻塞。
selector.select();
for(SelectionKey key : selector.selectedKeys()){
if(key.isAcceptable()){
ServerSocketChannel server =
(ServerSocketChannel)key.channel();
SocketChannel channel = server.accept();
channel.write(ByteBuffer.wrap(
new String("send message to client").getBytes()));
//在与客户端链接成功后，为客户端通道注册SelectionKey.OP_READ事件。
channel.register(selector, SelectionKey.OP_READ);
}else if(key.isReadable()){//有可读数据事件
SocketChannel channel = (SocketChannel)key.channel();
ByteBuffer buffer = ByteBuffer.allocate(10);
int read = channel.read(buffer);
byte[] data = buffer.array();
String message = new String(data);
System.out.println("receive message from client, size:"
+ buffer.position() + " msg: " + message);
}
}
}
NIO模型示例以下：
- Acceptor注册Selector，监听accept事件
- 当客户端链接后，触发accept事件
- 服务器构建对应的Channel，并在其上注册Selector，监听读写事件
- 当发生读写事件后，进行相应的读写处理
NIO优缺点
- 优势
- 性能瓶颈高
- 缺点
- 模型复杂
- 编码复杂
- 需处理半包问题
NIO的优缺点和BIO就彻底相反了!性能高，不用一个链接就建一个线程，能够一个线程处理全部的链接！相应的，编码就复杂不少，从上面的代码就能够明显体会到了。还有一个问题，因为是非阻塞的，应用没法知道何时消息读完了，就存在了半包问题！
半包问题
简单看一下下面的图就能理解半包问题了！
咱们知道TCP/IP在发送消息的时候，可能会拆包(如上图1)！这就致使接收端没法知道何时收到的数据是一个完整的数据。例如:发送端分别发送了ABC,DEF,GHI三条信息，发送时被拆成了AB,CDRFG,H,I这四个包进行发送，接受端如何将其进行还原呢？在BIO模型中，当读不到数据后会阻塞，而NIO中不会!因此须要自行进行处理!例如，以换行符做为判断依据，或者定长消息发生，或者自定义协议！
NIO虽然性能高，可是编码复杂，且须要处理半包问题！为了方便的进行NIO开发，就有了Reactor模型!
Reactor模型
- AWT Events
Reactor模型和AWT事件模型很像，就是将消息放到了一个队列中，经过异步线程池对其进行消费！
Reactor中的组件
- Reactor:Reactor是IO事件的派发者。
- Acceptor:Acceptor接受client链接，创建对应client的Handler，并向Reactor注册此Handler。
- Handler:和一个client通信的实体，按这样的过程实现业务的处理。通常在基本的Handler基础上还会有更进一步的层次划分， 用来抽象诸如decode，process和encoder这些过程。好比对Web Server而言，decode一般是HTTP请求的解析， process的过程会进一步涉及到Listener和Servlet的调用。业务逻辑的处理在Reactor模式里被分散的IO事件所打破， 因此Handler须要有适当的机制在所需的信息还不全（读到一半）的时候保存上下文，并在下一次IO事件到来的时候（另外一半可读了）能继续中断的处理。为了简化设计，Handler一般被设计成状态机，按GoF的state pattern来实现。
对应上面的NIO代码来看:
- Reactor：至关于有分发功能的Selector
- Acceptor：NIO中创建链接的那个判断分支
- Handler：消息读写处理等操做类
Reactor从线程池和Reactor的选择上能够细分为以下几种：
Reactor单线程模型
这个模型和上面的NIO流程很相似，只是将消息相关处理独立到了Handler中去了！
虽然上面说到NIO一个线程就能够支持全部的IO处理。可是瓶颈也是显而易见的！咱们看一个客户端的状况，若是这个客户端屡次进行请求，若是在Handler中的处理速度较慢，那么后续的客户端请求都会被积压，致使响应变慢！因此引入了Reactor多线程模型!
Reactor多线程模型
Reactor多线程模型就是将Handler中的IO操做和非IO操做分开，操做IO的线程称为IO线程，非IO操做的线程称为工做线程!这样的话，客户端的请求会直接被丢到线程池中，客户端发送请求就不会堵塞！
可是当用户进一步增长的时候，Reactor会出现瓶颈！由于Reactor既要处理IO操做请求，又要响应链接请求！为了分担Reactor的负担，因此引入了主从Reactor模型!
主从Reactor模型
主Reactor用于响应链接请求，从Reactor用于处理IO操做请求！
Netty
Netty是一个高性能NIO框架，其是对Reactor模型的一个实现！
- Netty客户端代码
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
EventLoopGroup workerGroup =
new NioEventLoopGroup();
try {
Bootstrap b =
new Bootstrap();
b.group(workerGroup);
b.channel(NioSocketChannel.class);
b.option(ChannelOption.SO_KEEPALIVE,
true);
b.handler(
new ChannelInitializer<SocketChannel>() {
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(
new TimeClientHandler());
}
});
ChannelFuture f = b.connect(host, port).sync();
f.channel().closeFuture().sync();
}
finally {
workerGroup.shutdownGracefully();
}
|
- Netty Client Handler
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class TimeClientHandler extends ChannelInboundHandlerAdapter {
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf m = (ByteBuf) msg;
try {
long currentTimeMillis =
(m.readUnsignedInt() -
2208988800L) * 1000L;
System.out.println(
new Date(currentTimeMillis));
ctx.close();
}
finally {
m.release();
}
}
public void exceptionCaught(ChannelHandlerContext ctx,
Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
|
- Netty服务端代码
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
EventLoopGroup bossGroup =
new NioEventLoopGroup();
EventLoopGroup workerGroup =
new NioEventLoopGroup();
try {
ServerBootstrap b =
new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.childHandler(
new ChannelInitializer<SocketChannel>() {
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(
new TimeServerHandler());
}
})
.option(ChannelOption.SO_BACKLOG,
128)
.childOption(ChannelOption.SO_KEEPALIVE,
true);
// Bind and start to accept incoming connections.
ChannelFuture f = b.bind(port).sync();
f.channel().closeFuture().sync();
}
finally {
workerGroup.shutdownGracefully();
bossGroup.shutdownGracefully();
}
|
- Netty Server Handler
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public class TimeServerHandler extends ChannelInboundHandlerAdapter {
public void channelActive(final ChannelHandlerContext ctx) {
final ByteBuf time = ctx.alloc().buffer(4);
time.writeInt((
int)
(System.currentTimeMillis() /
1000L + 2208988800L));
final ChannelFuture f = ctx.writeAndFlush(time);
f.addListener(
new ChannelFutureListener() {
public void operationComplete(ChannelFuture future) {
assert f == future;
ctx.close();
}
});
}
public void exceptionCaught(ChannelHandlerContext ctx,
Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
|
咱们从Netty服务器代码来看，与Reactor模型进行对应！
- EventLoopGroup就至关因而Reactor，bossGroup对应主Reactor,workerGroup对应从Reactor
- TimeServerHandler就是Handler
- child开头的方法配置的是客户端channel，非child开头的方法配置的是服务端channel
具体Netty内容，请访问Netty官网！
Netty的问题
Netty开发中一个很明显的问题就是回调，一是打破了线性编码习惯，
二就是Callback Hell！
看下面这个例子：
|
1
2
3
|
a.doing1();
//1
a.doing2();
//2
a.doing3();
//3
|
1,2,3处代码若是是同步的，那么将按顺序执行！可是若是不是同步的呢？我仍是但愿2在1以后执行，3在2以后执行！怎么办呢？想一想AJAX!咱们须要写相似以下这样的代码！
|
1
2
3
4
5
6
7
8
9
|
a.doing1(
new Callback(){
public void callback(){
a.doing2(
new Callback(){
public void callback(){
a.doing3();
}
})
}
});
|
那有没有办法解决这个问题呢？其实不难，实现一个相似Future的功能！当Client获取结果时，进行阻塞，当获得结果后再继续往下走！实现方案，一个就是使用锁了，还有一个就是使用RingBuffer。经测试，使用RingBuffer比使用锁TPS有2000左右的提升！
参考资料
- 1. 高性能IO模型浅析(转)
- 2. 高性能IO之Reactor模式（转载）
- 3. 高性能Server---Reactor模型
- 4. 【转载】[性能分析]Oracle数据库性能模型
- 5. 【转载】广义线性模型
- 6. Netty高性能之Reactor线程模型
- 7. 高性能IO模型浅析
- 8. 理解高性能网络模型
- 9. 高性能网络IO模型
- 10. Netty高性能架构模型介绍
- 更多相关文章...
- • ASP.NET MVC - 模型 - ASP.NET 教程
- • C# 类型转换 - C#教程
- • 委托模式
- • Kotlin学习（二）基本类型
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 升级Gradle后报错Gradle‘s dependency cache may be corrupt (this sometimes occurs
- 2. Smarter, Not Harder
- 3. mac-2019-react-native 本地环境搭建(xcode-11.1和android studio3.5.2中Genymotion2.12.1 和VirtualBox-5.2.34 )
- 4. 查看文件中关键字前后几行的内容
- 5. XXE萌新进阶全攻略
- 6. Installation failed due to: ‘Connection refused: connect‘安卓studio端口占用
- 7. zabbix5.0通过agent监控winserve12
- 8. IT行业UI前景、潜力如何？
- 9. Mac Swig 3.0.12 安装
- 10. Windows上FreeRDP-WebConnect是一个开源HTML5代理，它提供对使用RDP的任何Windows服务器和工作站的Web访问
- 1. 高性能IO模型浅析(转)
- 2. 高性能IO之Reactor模式（转载）
- 3. 高性能Server---Reactor模型
- 4. 【转载】[性能分析]Oracle数据库性能模型
- 5. 【转载】广义线性模型
- 6. Netty高性能之Reactor线程模型
- 7. 高性能IO模型浅析
- 8. 理解高性能网络模型
- 9. 高性能网络IO模型
- 10. Netty高性能架构模型介绍