Linux C++服务器程序设计范式
《Unix网络编程》30章详细介绍了几种服务器设计范式。总结了其中的几种,记录一下;
多进程的做法:
1.每次创建一个新的请求,fork一个子进程,处理该连接的数据传输。
2.预先派生一定数量的子进程,每个子进程都调用accept接收连接请求。当一个请求到来之后会触发所有进程的accept,但是只有最先的子进程会处理该请求。这就是所说的“惊群”。
3.为了解决“惊群”,在各个子进程的accept前后都用线程的互斥锁来做同步保护。一般来说互斥锁用于线程之间的同步,但是也可用作多个进程之间同步,具体用法参考链接。http://blog.csdn.net/dlutbrucezhang/article/details/8834387
和多进程的做法相对应,只是线程更轻,理论上开销更小。
1.每次创建一个新的请求,fork一个子线程,处理该连接的数据传输。
2.预先派生一定数量的子线程,每个子进程都调用accept接收连接请求。当一个请求到来之后会触发所有线程的accept,但是只有最先的子线程会处理该请求。这就是所说的“惊群”。
3.为了解决“惊群”,在各个子线程的accept前后都用线程的互斥锁来做同步保护。
一般来说,第一种方法可以对付一般的连接请求量,比如我研究生科研做的每次就我一个人访问的,或者我和老师同时访问的一个小型服务器,这样的足够了。第三种就比较好了,响应非常迅速,时间上差不多比第一种快了十倍以上,而且第三种编码也比较简单。
这本书上还提供了对文件加锁,主线程accept传递给子线程等等办法,编码都比较麻烦,效果也一般。
另外之前我的博客http://www.cnblogs.com/shenshenlei/p/5535853.html 中提到epoll 的问题。其实那个源代码中派生几个线程,每个线程都是epoll_wait,这个编码和在多线程中accept非常相似,但是也没有用到互斥量做线程安全。参考链接 https://rocfang.gitbooks.io/dev-notes/content/acceptyu_epoll_liang_qun.html给出了关于该问题的一些描述,“accept 已经不存在惊群问题,但 epoll 上还是存在惊群问题。即,如果多个进程/线程阻塞在监听同一个 listening socket fd 的 epoll_wait 上,当有一个新的连接到来时,所有的进程都会被唤醒。”如作者所说,关于此问题nginx给出的解决方案也是加一个互斥锁。
(2016-6-2 15:21:01再次更新)
在Linux2.6内核中已经解决了accept导致的惊群问题。
在Linux3.9内核中提出了要解决epoll_wait惊群问题,而且在内核4.5中,正式得到解决。在这个版本中添加了一个EPOLLEXCLUSIVE 标记。内核代码根据此标记为会有选择性的唤醒一个阻塞在epoll_wait上的进程(线程)。但显然这个版本距离大规模的使用还有很遥远的距离。参考链接:https://github.com/torvalds/linux/commit/df0108c5da561c66c333bb46bfe3c1fc65905898
参考链接:
http://blog.csdn.net/dlutbrucezhang/article/details/8834387
http://www.cnblogs.com/shenshenlei/p/5535853.html
https://rocfang.gitbooks.io/dev-notes/content/acceptyu_epoll_liang_qun.html