服务器接受的链接过多，该怎么处理

每当客户端有一个请求链接时，服务器就accept，然后建立一个线程;但是服务器新建的线程有上限，例如1000; 
当同时有1500个请求链接时，服务器只能处理1000个请求，产生1000个线程，这1000个线程都处于忙碌状态;那么剩下的500的服务器改怎么处理？ 
方法：建立一个列队来存储这500个请求可以吗？我担心在等待服务器出现空闲线程时，等待时间过长，链接断开了 

各位有什么好的方法来处理这个情况吗

------解决方案--------------------

探讨

引用:

我以前在一家公司实习的时候做媒体服务器
媒体资源管理哪一块刚好是我负责的
如果外部有呼叫，需要建立连接，就首先需要分配资源，如果资源不足就返回433（msml里面定义的）

你的意思是不管这500个链接？

------解决方案--------------------

探讨

用队列来处理是没有悬念的。。


如果你是用户，人家把你丢了，你心里肯定不舒服。所以，用队列比较合适。

------解决方案--------------------
一个连接对应一个线程的设计本身就是有瓶颈的，建议使用iocp或者epoll来实现。
这样使用几个线程就可以处理上千个连接的io操作。
同时还应该使用消息队列，把真正的逻辑操作放到逻辑线程中。
网上有很多例子的，可以找一下，并不复杂。

------解决方案--------------------
select模型不行吗？通常建立一个线程Accept接收客户端连接，将连接扔进接收数据线程，状态机进行数据处理，扔给发送线程回应客户端。其他的根据你的需要确定是否需要多线程处理，good luck。如果性能确实上不去再在处理线程那里采用多线程。socket的TCP关键是Accept，Send，Recv是阻塞的。此外TCP编程还应处理实际接收和发送的数据。
------解决方案--------------------
epoll & IOCP
------解决方案--------------------
linux就可以先用 epoll模型.
Window 就可以选择 IOCP模型.两者各有优缺点.

不过呢,1500个连接用1500个线程处理,显然是不妥的.我想CPU花在切换上的时间都不知道花了多少了.

楼主去baidu一下,这两个模型吧. 

------解决方案--------------------
可以用listen 建立一个队列，队列大小最小>1500，有连接请求是就会建立连接，在系统内核当中他会把所需要连接的请求分为2部分，一部分为已连接队列，另一部分就是未连接队列，当已连接队列为空时就会阻塞，在未连接队列中的队头就会建立TCP 3次握手连接，加入到已连接队列中。随后进行处理，所以没必要担心现成会在空闲的时等待时间过长断开连接。希望这些对你有帮助
------解决方案--------------------
瓶颈在于线程个数有限制..

用epoll检测监听套接字与已连接套接字,将新的连接套接字加入到集合里,将已连接套接字的数据到来作为一个task加入到全局队列里,唤醒一个线程去处理.

传统的都是一个客户对应一个线程,始终占有直到客户端断开连接.

现在是一个请求对应一个线程,处理结束便放掉了线程,所以一个线程已经不是在对应一个客户了,而是对应千千万万客户的千千万万个请求.

你应该知道线程里死循环,阻塞在条件变量上的,只有主线程给予通知才能唤醒,一旦唤醒,那么由于死循环检测缘故,如果我们只有1000个线程,而来了8000个请求,主线程不管3721,将8000个请求都加入队列,并且唤醒8000次,而实际唤醒1000次就唤醒了所有线程,而每个线程都是轮训检测的,所以将最终取完并处理所有在全局队列里的请求.

这就是一个线程对应多个客户,线程的工作周期不是和客户生命周期一样,而是随每一次请求而运作的.
------解决方案--------------------
我也觉得对，使用epoll来做的话，那就是对着的是千千万万个请求的问题，而不是接受连接的问题了。

1：master+worker 处理，主进程负责创建监听 sockfd， 子进程负责epoll处理各个事件发生，检测到各个事件是读写事件或accept 进入不同队列。

2：各个进程对于处理accept事件接入时，使用锁来防止发生群惊，这样也会使得各个进程负载均匀。

3：各个子进程里面维护的是各自其accept上来的 sockfd, 那么这就会，即使其中一个子进程退出了，也不至于全部client退出，并且主进程可以通过信号来检测得到哪个子进程非正常退出了，然后重新建立进程。


看你业务需要，不是文件大信息类型的服务器，应该不用一条线程一个用户也处理的过来吧？