大容量高并发性服务器组的技术解析

摘要: 本文对目前即时通讯服务器现状做了分析,并介绍了能满足大容量高并发性的网络负载均衡技术。总结了服务器端的windows完成端、epoll模型、线程池和p2p等相关技术,并进一步提出了展望。 
  关键词: 大容量;并发性;负载均衡;服务器构架 
  中图分类号:TP368.5 文献标识码:A 文章编号:1006-4311(2014)01-0192-02 
  0 引言 
  Internet的快速增长使多媒体网络服务器面对的访问数量快速增加,要求服务器具备提供高并发连接数的能力,这对网络服务提供商提出了巨大的挑战[1]。并发连接数是指代理服务器对其业务信息流的处理能力,是代理服务器能够同时处理的点对点连接的最大数目,它反映出代理服务器设备对多个连接的访问控制能力和连接状态跟踪能力。单台服务器的性能有限,这是由服务器本身的处理能力和I/O能力决定的,必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。 
  对于整个即时通讯(IM)服务器端体系,以及游戏服务器端的体系,一般都采用登陆服务器集群和应用服务器集群来分别处理登录和应用服务。组建分布式服务器群可以有效地均衡负载。负载均衡是解决高负荷访问和大容量并发请求普遍采用的解决办法。它能让多台服务器或多条链路共同承担一些繁重的计算或I/O任务,从而以较低成本消除网络瓶颈,提高网络的灵活性和可靠性。网络负载均衡自动检测到服务器不可用时,能够迅速在剩余的服务器中重新指派客户机通讯,此保护措施能够帮助为关键业务程序提供不中断的服务。同时,可以根据网络访问量的增多,来增加网络负载均衡服务器的数量。[2] 
  在面对大量用户访问、高并发请求方面,解决方案主要集中在以下几点:良好的服务器组架构,高效率的服务器端程序、高性能的数据库、高效率的编程语言、还有高性能的Web容器。其中,服务器组架构和高效率的服务器端程序显得尤为重要。 
  1 大容量并发性服务器组的架构 
  良好的服务器组架构能够更好的进行负载均衡工作。如图1所示。 
  服务器组架构的考虑因素包括: 
  1.1 稳定性 稳定提供服务,是服务器系统确保用户体验的最基本要求。稳定性主要与应用服务器的软件质量相关。 
  1.2 效率 服务器组的运行时效率主要体现在服务器系统的承载能力上。 
  1.3 可缩放性 可缩放性可以理解为:增加服务器硬件是否可以相应的提高系统的负载能力或者是否能提高用户体验。承载能力和用户体验都是系统表现的一部分。从游戏开发及运营的角度来考虑,因素还包括: 
  1.4 生产力、开发效率 服务器的架构设计不止要考虑系统运行时的效率,也要考虑开发时的工作效率。例如:不同的系统服务或应用服务器之间是否会过度耦合等。 
  1.5 简单 简单性要体现在服务器组的部署和维护方面。如果一个游戏服务器组有20台硬件,那么备份数据、更新、重启这种简单的事情都会不再简单。一般游戏服务商每周都只做两小时停机维护,20组服务器的话,都会消耗大量的人力、物力。 
  1.6 可扩展性 实际上考虑到网络游戏服务的持续性,可扩展性也很重要,一般的做法就是周期性的持续提供游戏更新。可扩展性在架构设计阶段就应该考虑到。 
  2 实现大容量并发性的服务器端程序采用的技术 
  在IM方面,实现大容量并发性的服务器端程序,总结起来主要有以下技术:提高系统内核I/O性能,线程池和P2P。 
  2.1 提高系统内核I/O性能 开发网络程序一般需要创建socket,发起连接,接受连接,发送和接受数据。让程序可以适应从单单一个连接到几千个连接乃至于上万个连接是真正的难点。尽量提高单台服务器I/O性能是首先需要考虑的,利用Windows平台完成端口进行重叠I/O的技术和Linux的内核中引入的EPOll技术,是目前提高系统内核I/O性能的很好方法。 
  2.1.1 WINDOWS完成端口编程[3] 重叠I/O是指当调用了某个函数(比如ReadFile)就立刻返回做自己的其他动作的时候,同时系统也在对I/0设备进行操作,在这段时间内程序和系统的内部动作是重叠的,因此有更好的性能。所以,重叠I/O是用于异步方式下使用I/O设备的。 
  Win32重叠I/O机制允许发起一个操作,在操作完成之后接受到信息。对于耗费时间比较长的操作来说,重叠IO机制可以使发起重叠操作的线程在重叠请求发出后就释放掉。我们可以把完成端口看成系统维护的一个队列,操作系统把重叠IO操作完成的事件通知放到该队列里,由于是暴露 “操作完成”的事件通知,所以命名为“完成端口”(Completion Ports)。一个socket被创建后,可以在任何时刻和一个完成端口联系起来。windows的完成端口机制在操作系统内部已经作了优化,提供了更高的效率。 
  2.1.2 Linux的EPoll模型 Epoll I/O多路复用技术是Linux 2.6内核中提高网络I/O性能的新方法,多使用在TCP网络服务器中。Epoll是为处理大批量句柄而作了改进的poll。Epoll是一种高效的管理socket的模型,相比于select,epoll最大的好处在于首先它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中,它是采用轮询来处理的,轮询的fd数目越多耗时越多。Epoll所支持的fd上限是最大可以打开文件的数目,这个数字一般远大于2048;其次,IO效率不随fd数目增加而线性下降,在内核实现中epoll是根据每个fd的callback函数实现的,只有“活跃”的socket才会主动的去调用callback函数,其他idle状态socket则不会,在这点上,epoll实现了一个“伪”AIO,因为这时候推动力在os内核。 
  2.2 线程池thread-pool 传统多线程方案中服务器端模型是接受到请求,即创建一个新的线程执行任务,完毕后退出,这就是“即时创建,即时销毁”的策略。如果提交给线程的任务是执行时间较短,而且执行次数极其频繁,那么服务器处于不停的创建线程,销毁线程的状态。线程池采用预创建的技术,在应用程序启动之后,把立即创建一定数量的线程(N1),放入空闲队列中。这些线程都是处于阻塞(Suspended)状态,不消耗CPU,但占用较小的内存空间。当任务到来后,缓冲池选择一个空闲线程,把任务传入此线程中运行。当N1个线程都在处理任务后,缓冲池自动创建一定数量的新线程,用于处理更多的任务。在任务执行完毕后线程也不退出,而是继续保持在池中等待下一次的任务。当系统比较空闲时,大部分线程都一直处于暂停状态,线程池自动销毁一部分线程,回收系统资源。基于这种预创建技术,线程池把线程创建和销毁本身所带来的开销分摊到了各个具体的任务上,执行次数越多,每个任务所分担到的线程本身开销则越小。但是线程之间同步所带来的开销还需要考虑。   2.3 P2P P2P是点对点传输,P2P与传统的少数服务器服务多个用户的C/S服务模式不同,大部分的服务靠用户间互相提供服务完成。[4] 
  P2P技术属于覆盖层网络(Overlay Network)的范畴,是相对于客户机/服务器(C/S)模式来说的一种网络信息交换方式。由于能够极大缓解传统架构中服务器端的压力过大、单一失效点等问题,又能充分利用终端的丰富资源,所以P2P技术被广泛应用于计算机网络的各个应用领域。P2P的基本原理是容易实现的,人们的研究方向也由基础架构的构建和维护及优化算法等桎梏中摆脱出来,开始深入到P2P技术的根本性问题中去。最新的研究成果表明,不少研究人员已经开始将重心转入到覆盖层网络的节点延时聚集研究、覆盖网之间(Inter-Overlay)优化研究、P2P支撑平台研究以及P2P安全方面的研究等方面。 
  3 展望 
  随着3G时代的到来,我们也对网络的大容量并发性控制提出了更高的要求,在现有的技术开发基础上,可以采用多核CPU来提高服务器性能、优化内核以增大系统最大网络并发连接数等。在服务器组构架设计方面可以根据用户的使用习惯,细分分区,减少单个数据库的压力,使服务器对于分区的变化能够给与相应的支持;使用复杂的策略,根据系统压力分布对用户登录的分配可以方便的调整;通过提高系统的配置性,可以实现不停的通过简单堆叠扩展系统容量,使系统随用户数量增加不断扩大。 
  参考文献: 
  [1]J. Almeida, V. Almeida, and D. Yates. Measuring the Behavior of a World-Wide Web Server. Technical Report TR-96-025, Boston University, CS Dept., Boston MA, 1996. 
  [2]朱利,张兴军.Web服务器组的负载均衡方法研究[J].小型微型计算机系统,2003(12). 
  [3]R. Abbott and H.Garcia-Molina. Seheduling I/O requests with Deadlines: A Performance Evaluation. Proceedings of the IEEE Real-Time Systems Symposium,113-124, Lake Buena Vista,Florida,USA,December 1990. 
  [4]Ananth Rao, Karthik Lakshminarayanan, Sonesh Surana, Richard Karp, and Ion Stoica, Load Balancing in Structured P2P Systems, in Proc. IPTPS, Feb. 2003.

posted @ 2014-05-24 10:47  wayguan  阅读(1668)  评论(0编辑  收藏  举报