阻塞IO服务器模型之多线程服务器模型

针对单线程服务器模型的特点,我们可以对其进行改进,使之能对多个客户端同时进行响应。最简单的改进即是使用多线程(或多进程)服务器模型,在应用层级别,我们一般采用多线程模式。多线程能让多个客户端同时请求,并能几乎同时对这些请求进行响应,而不用排队一个一个处理,能同时为多个客户端提供一问一答的服务。

图2-6-1-2 多线程阻塞服务器模型

多线程服务器模型核心就是利用多线程机制,为每个客户端分配一个线程。如图2-6-1-2,服务器初始化一个Serversocket实例,绑定某个端口号,并使之监听客户端的访问。两个客户端几乎同时过来请求,服务器在接收到客户端请求后,创建两条线程进行处理,直到响应完成。在这过程中,服务器只是简单的负责接收消息,然后交给处理者线程来处理,服务器能在短时间内接收多个客户端的请求。

这种模型也是阻塞式的,因为每个线程向客户端写入消息并不是马上返回的,图2-6-1-2中黑块这段时间片就是阻塞时间。但这种模式比单线程处理性能明显高了,不用等到第一个请求处理完才处理第二个。对于多线程,如果线程数大于CPU数量,那么操作系统将会在多个线程之间调度,从而使其他线程能使用CPU,每调度一次导致一次上下文切换,大多通用的处理器中,每次调度大概需要5000-10000个时钟周期,大概几微妙。

用这种多线程服务器模型就能真正地完美解决问题了吗?其实不然,随着客户端的数量越来越多,当达到成百上千路连接请求时,多线程操作会严重消耗系统cpu资源,并且多线程更容易进入假死状态。对此提出了“线程池”的概念,线程池在启动时先把一定数量的线程先创建好放到内存中,并且使用完不真正销毁线程,而是放回池里,以供新任务使用。这种缓存池机制能有效减少线程创建与销毁的频率,大大降低系统开销。这种机制在Tomcat中也是有所体现,如图2-6-1-3,当一个请求过来时尝试从池里获取一个线程,如果有空闲线程则返回一个线程供使用,而如果没有空闲线程了则直接关闭socket连接拒绝服务,保证服务器在处理能力范围内运行

图2-6-1-3 多线程阻塞服务器模型-线程池

多线程服务器模型的特点:能支持对多个客户端同时进行响应,处理能力得到大大的提高,有较大的并发量,但服务器系统资源消耗较大,同时拥有较复杂的结构,实现的代码也相对比较复杂。这种模型适用于访问并发量较大,请求是短期的、无状态的,业务逻辑比较复杂,对响应时间要求较高的场合。

阻塞IO服务器模型之多线程服务器模型,布布扣,bubuko.com

时间: 2024-10-19 20:21:44

阻塞IO服务器模型之多线程服务器模型的相关文章

一起来写web server 06 -- 单线程非阻塞IO版本

阻塞IO的效率是在是低下,你如果要写高性能的web server的话,你必须使用非阻塞IO. 非阻塞IO的读写 在谈到非阻塞IO之前,必须先谈一谈阻塞IO,在网络编程中,我们假设有一个监听套接字的sockfd,这个sockfd是你调用了socket,listen, bind这一大票的函数得到的一个文件描述符.其实它默认就是阻塞的,具体的表现是: 使用accept函数监听sockfd时,如果没有连接到来,这个函数会一直阻塞在那里. 对sockfd调用recv函数的时候,如果对方还没有发送数据过来,

非阻塞IO服务器模型

我们来考虑一个情形,你跟千千万万个玩家是魔兽世界的超级粉丝,每周末准时组团打boss.每当周末游戏服务器就亚历山大,因为起码几十万用户同时在线.如果用我们的多线程阻塞服务器作为游戏服务器是否可行呢?先分析游戏服务器有哪些特点: ①  网络游戏并非像网页一样,打开一旦下载完就可以关闭连接结束.网游必须是有一个持久有状态的连接,每一个客户端都需要跟服务器存在一个持久的连接,以便快速及时发送消息.而随着并发用户数量的增加,多线程阻塞服务器不可能为每一个客户端分配一个线程. ②  跟一般的应用服务器不同

阻塞IO服务器模型之单线程服务器模型

单线程服务器模型是最简单的一个服务器模型,几乎我们所有程序员在刚开始接触网络编程(不管是B/S结构还是C/S结构)都是从这个简单的模型开始.这种模型只提供同时一个客户端访问,多个客户端访问必须要等到前一个客户端访问结束,一个一个排队,即提供一问一答服务. 图2-6-1-1 单线程阻塞服务器模型 图2-6-1-1展示了单线程阻塞服务器是怎样响应客户端的访问.首先,服务器必须初始化一个Serversocket实例,绑定某个端口号,并使之监听客户端的访问,以此提供一种服务.接着客户端1远程调用服务器的

从操作系统内核看Java非阻塞IO事件检测

非阻塞服务器模型最重要的一个特点是,在调用读取或写入接口后立即返回,而不会进入阻塞状态.在探讨单线程非阻塞IO模型前必须要先了解非阻塞情况下Socket事件的检测机制,因为对于非阻塞模式最重要的事情是检测哪些连接有感兴趣的事件发生,一般会有如下三种检测方式. 应用程序遍历socket检测 如图所示,当多个客户端向服务器请求时,服务器端会保存一个socket连接列表,应用层线程对socket列表进行轮询尝试读取或写入.对于读取操作,如果成功读取到若干数据则对读取到的数据进行处理,读取失败则下个循环

[Z] linux基础编程:IO模型:阻塞/非阻塞/IO复用 同步/异步 Select/Epoll/AIO

原文链接:http://blog.csdn.net/colzer/article/details/8169075 IO概念 Linux的内核将所有外部设备都可以看做一个文件来操作.那么我们对与外部设备的操作都可以看做对文件进行操作.我们对一个文件的读写,都通过调用内核提供的系统调用:内核给我们返回一个file descriptor(fd,文件描述符).而对一个socket的读写也会有相应的描述符,称为socketfd(socket描述符).描述符就是一个数字,指向内核中一个结构体(文件路径,数据

linux基础编程:IO模型:阻塞/非阻塞/IO复用 同步/异步 Select/Epoll/AIO(转载)

IO概念 Linux的内核将所有外部设备都可以看做一个文件来操作.那么我们对与外部设备的操作都可以看做对文件进行操作.我们对一个文件的读写,都通过调用内核提供的系统调用:内核给我们返回一个file descriptor(fd,文件描述符).而对一个socket的读写也会有相应的描述符,称为socketfd(socket描述符).描述符就是一个数字,指向内核中一个结构体(文件路径,数据区,等一些属性).那么我们的应用程序对文件的读写就通过对描述符的读写完成. linux将内存分为内核区,用户区.l

实现一个非阻塞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 * */

python(十)下:事件驱动与 阻塞IO、非阻塞IO、IO多路复用、异步IO

上节的问题: 协程:遇到IO操作就切换. 但什么时候切回去呢?怎么确定IO操作完了? 一.事件驱动模型介绍 通常,我们写服务器处理模型的程序时,有以下几种模型: (1)每收到一个请求,创建一个新的进程,来处理该请求: (2)每收到一个请求,创建一个新的线程,来处理该请求: (3)每收到一个请求,放入一个事件列表,让主进程通过非阻塞I/O方式来处理请求 第三种就是协程.时间驱动的方式,一般普遍认为第(3)种方式是大多数网络服务器采用的方式 论事件驱动模型 在UI编程中,,常常要对鼠标点击进行相应,

异步IO比同步阻塞IO性能更好吗?为什么?

最近在看node.js, 介绍中提到node是异步io的方式实现, 性能比同步阻塞io的更好. 对于一个request而言, 如果我们依赖io的结果, 异步io和同步阻塞io都是要等到io完成才能继续执行. 而同步阻塞io, 一旦阻塞就不会在获得cpu时间片, 那么为什么异步的性能更好呢? 这个问题之前在做Servlet AIO优化的时候就没想太明白. 现在回想起来tomcat这类server的NIO并发数是有瓶颈的, 即便是空跑也只能到1000个并发量级, 而Nginx可以做到C10k. 问题