非阻塞IO服务器模型
来源:互联网 发布:恐惧未来知乎 编辑:程序博客网 时间:2024/06/10 06:58
我们来考虑一个情形,你跟千千万万个玩家是魔兽世界的超级粉丝,每周末准时组团打boss。每当周末游戏服务器就亚历山大,因为起码几十万用户同时在线。如果用我们的多线程阻塞服务器作为游戏服务器是否可行呢?先分析游戏服务器有哪些特点:
① 网络游戏并非像网页一样,打开一旦下载完就可以关闭连接结束。网游必须是有一个持久有状态的连接,每一个客户端都需要跟服务器存在一个持久的连接,以便快速及时发送消息。而随着并发用户数量的增加,多线程阻塞服务器不可能为每一个客户端分配一个线程。
② 跟一般的应用服务器不同,CS结构的网络游戏一般把复杂的逻辑处理放到了客户端,而在游戏服务器端只处理比较简单的逻辑,甚至只是传递消息。像这样简单的逻辑我们竟然给每一个请求分配一条线程,这是不是严重脱离实际了?
③ 网游讲求的是响应快,消息交换及时,并且能进行双向通信,那必然需要频繁请求跟响应,假如我们已经采用了长久连接,但服务器并不是每次都有新数据,并不需要发送给客户端,那我们还占了一条线程,是不是太浪费了?
从以上几点分析,像网游这样的场合,我们传统的多线程服务器显然已经力不从心。线程池能在一定程度上缓解频繁的IO调用带来的资源占用,但池有一定的大小限制,在面对成千上万的客户端请求大并发情况下,却始终不是最佳方案。有没有可能用一个或少量的线程就可以维护很多持久连接呢?下面介绍一种新的服务器模型——非阻塞服务器模型。
非阻塞服务器模型最重要的一个特点是,在调用某个接口后立即返回,而不会阻塞等待。如图2-6-2-1中所展示,当多个客户端向服务器请求时,服务器端会保存一个socket连接列表,然后有一个专门的线程对这个列表进行轮询。如果发现某个socket有数据可读,就调用该socket的相应的读操作;反之,发现socket有数据可写的话,就调用该socket的相应的写操作;如果发现某个socket已经中断,就调用socket关闭操作。为了有更好地性能,还可以结合线程池,一旦检测到有需要处理(读数据、写数据、关闭)的socket就启动另外一条线程负责处理。
图2-6-2-1 非阻塞服务器模型
这样看来,不管多少个socket连接都可以被一条线程管理起来,一条线程负责遍历这些socket列表,处理再交给线程池,很好地利用了阻塞的时间,处理能力得到提升。但这种模型涉及到遍历所有的socket列表,同时需要处理数据的拼接,空闲时也占用较多CPU资源,仍然不适于大并发场景。再稍做改进——事件驱动模型。它的核心是事件驱动,线程遍历的并非socket列表,取而代之的是检测事件,对检测出来的事件进行逐一响应。极大提高了检测效率,自然处理能力也更强。
喜欢研究java的同学可以交个朋友,下面是本人的微信号:
- 非阻塞IO服务器模型
- IO模型:同步、异步、阻塞、非阻塞
- IO模型之阻塞、非阻塞、IO多路复用、异步
- python基础-io模型、阻塞、非阻塞、io多路复用
- 嵌入式Web服务器学习之阻塞IO/非阻塞IO
- 图像检索服务器编写问题记录——服务器端模型选择+epoll和非阻塞IO
- 实现一个非阻塞IO的服务器
- 网络IO模型:同步IO和异步IO,阻塞IO和非阻塞IO
- 5种IO模型、阻塞IO和非阻塞IO、同步IO和异步IO
- 网络模型:阻塞IO,非阻塞IO,IO复用,信号驱动IO,异步IO
- socket阻塞/非阻塞,同步/异步,io模型
- IO模型:同步与异步,阻塞与非阻塞
- 【IO模型探讨】阻塞,非阻塞,同步,异步
- 网络IO模型(同步异步,阻塞非阻塞)
- IO模型(同步,异步,阻塞,非阻塞)
- 6. 文件IO模型的实现 ---阻塞 和 非阻塞
- IO 模型简介(理解阻塞、非阻塞、同步、异步)
- 深度理解IO模型-同步异步,阻塞非阻塞
- 【机房收费系统】-1-添加、连接数据库文件
- Java应用服务器 Tomcat
- Merge k Sorted Lists
- Mashmokh and ACM - CodeForces 414B dp
- zoj 1530
- 非阻塞IO服务器模型
- 设计模式(Design Patterns)
- OJ--分配糖果
- 开源ETL工具 Kettle
- 在Ubuntu14.04下使用ap-hotspot建立无线热点(AP mode)
- George and Cards - CodeForces 387E 树状数组
- 链栈
- 华为机试 - 火星计算器
- Java中写代码的快捷方式