书接上文，很自然地就到了高性能服务器设计这个话题上来了。
先后查看了，和的相关源码，无一例外，他们一致认为多路复用是性能最好的服务器架构。事实也确实应该如此，进程的出现一方面就是为了保存任务的执行上下文从而简化应用程序设计，如果程序的逻辑结构不是很复杂，那么用整个进程控制块来保存执行上下文未免有些大材小用，加上进程调度和其他的一些额外开销，程序设计上的高效很可能会被执行时的低效所抵消。代价也是有的：程序设计工作将更加具有挑战性。
体系结构选定之后，我们就要考虑更加细节的部分，比如说用什么操作系统，用操作系统提供的那些API。在这方面，前辈们已经做过很多，我们只需要简单的“拿来”即可，如果再去枉费唇舌，简直就是浪费时间，图财害命。从根本上分析了导致服务器低效的罪魁祸首：数据拷贝、（用户和内核）上下文切换、内存申请（管理）和锁竞争;列举并分析了UNIX、Linux甚至是部分Windows为提高服务器性能而设计的一些系统调用接口，这篇文档的难能可贵之处还在于它一致保持更新;更是通过实测数据用图表的形式把BSD和Linux的相关系统调用的性能直观地陈列在我们眼前，结果还是令人激动的：Linux 2.6的相关系统调用的时间复杂度竟然是O(1)。
简单的总结如下:
- 操作系统采用Linux 2.6.x内核，不仅因为它的高性能，更因为它大开源（这并不是说其他的UNIX或者是BSD衍生物不开源）给程序设计带来的便利，我们甚至可以把服务做到内核空间。
- 多路复用采用epoll的“电平触发”(Level Triggered)模式，必要时可以采用“边缘触发”(Edge Triggered)，但要注意防止数据停滞。
- 为避免数据拷贝可以采用sendfile系统调用发送小文件，或者是文件的小部分，注意避免sendfile因磁盘IO而导致的阻塞。
- 如果服务操作设计大量磁盘IO操作，应选用，其对应的用户空间库为libaio，注意：这里提到异步IO库并非目前glibc中附带的异步IO实现。
- 如果同时有多个数据需要传输，采用writev/readv来减少系统调用所带来的上下文切换开销，如果数据要写到网络套接字文件描述符，这也能在一定程度上防止网络上出现比较小帧，为此，还可以有选择地开启TCP_CORK选项。
- 实现自己的内存管理，比如说缓存数据，复用常用数据结构等。
- 用多线程替代多进程，线程库当然选择nptl。
- 避免进程/线程间非必要的同步，保持互斥区的短小。
上面这些琐碎的细节在ESR看来可能都是过早优化，他可能又会建议我们等待硬件的升级。哈哈，提醒还是不无道理的，算法的设计部分，我们更要下大力气，因地制宜地降低算法的时间复杂度。为什么不提空间复杂度呢？内存的价格还是相对低廉吧，不过还是不要忘记现在的计算机瓶颈多在内存的访问。
有一点需要提醒一下，目前SMP系统和多核心CPU比较常见，如果还是仅采用单进程（线程）的多路复用模型，那么同一时间将只有一个CPU为这个进程（线程）服务，并不能充分发挥CPU的计算能力，所以需要至少CPU（CPU核心）数目个进程（线程）来分担系统负担。有一个变通的解决方案：不用修改源码，在服务器上运行两个服务程序的实例，当然这个时候服务端口应该是不同的，然后在其前端放置负载均衡器将流量和连接平均分配到两个服务端口，可以简单的通过DNAT来实现负载均衡。其实，这个时候我们已经把多CPU或者是多核系统看成了多个系统组成的集群。
为了提高服务器的性能，单纯的依靠提高单个服务器的处理能力似乎不能奏效，况且配置越高的服务器花销也就越高，为此人们经常采用服务器集群的方式，通过把计算尽可能地分配到相对比较廉价的机器上单独完成，籍此来提升服务器的整体性能，事实证明，这种体系结构不仅是切实可行的，而且还能提高服务器的可用性，容错能力也较强。在网络服务器方面，Linux内核中的由国人先生设计的IP层负载均衡解决方案比较有名，还有就是工作于应用层的haproxy和刚刚起步的l7sw。
参考链接:
阅读(4967) | 评论(1) | 转发(8) |
