大并发服务器的问题

iunknown

原帖由 yang_crystal 于 2008-2-2 14:38 发表
假设一个服务器要处理1000个客户端连接（TCP长连接），要为每一个客户端保持一个连接。
1、是不是要创建1000个线程（进程）来处理这些客户端的请求？
2、假设一个线程处理一个客户端的话，如果这个客户端发出的请求很快的话，
    而且这个线程处理一个请求的时间很慢，岂不是后面的请求要丢失？
不知道怎么去处理！！
大大们给个好的解决方案啊，谢谢了先

连接数和线程数没有必然的联系。关于如何使用线程来处理 TCP 长连接，在 linux 平台下常见的有以下几种策略：
1.基于事件驱动的单线程方式，比如 memcached 使用 libevent
2.基于ThreadPerConnection，就是一个连接一个线程
3.结合线程池和事件驱动，使用 半异步半同步 或者 Leader/Follower 的策略

>> 如果这个客户端发出的请求很快的话，而且这个线程处理一个请求的时间很慢，岂不是后面的请求要丢失

和这个问题最相关的其实不是采用什么线程策略，而是 Client/Server 之间的协议是怎么设计的。
如果 Client/Server 之间是 半双工的协议，类似于 smtp/pop 这类的协议，即使采用 ThreadPerConnection 也不会存在问题。
如果 Client/Server 之间是 全双工的协议，并且 Server 处理一个请求需要比较长的时间，那么最好的方法是结合线程池和事件驱动的方式来实现。
如果 Server 处理请求所需的时间极短，比如 memcached ，那么使用单线程就行了。

net_robber

原帖由 yang_crystal 于 2008-2-14 15:02 发表
短连接存在一个问题，有时候服务器需要去主动连接在线的客户端，如果客户端在私网的话怎么找到在线客户端？
用select判断连接可读可以吗？如果可以的话那么同时有500个客户端在线的话岂不是要判断500次啊？
( ...

如果连接没有断掉，直接发送数据似乎就可以了


当然，如果你说的是P2P模式的传输，就是另外一码事了

scuhkr

是不是要创建1000个线程（进程）来处理这些客户端的请求？
可以的，同步做法，  1000 个线程未必不可以，现在的os 可以做到的。好处是代码简单。缺点很明显， 不能扩展。线程的切换无法保证。

1000个线程基本可以否掉。想想32位的机器内存单进程只有2G内存可用，1个线程将至少占用8M的线程空间（当然可以调小），那么2000/8 约=300个线程已经顶了。

lz的需求还没讲清楚吧。如果再具体点，可能会比较好分析用何种网络框架。

yang_crystal

其实也就是一个客户端的接入服务器，但有时候需要主动连接在线的客户端，
前提：客户端和接入服务器是TCP长连接
接入服务器的主要作用是接收客户端的请求，到认证服务器认证一下，等待认证结果，然后转发到相应的应用服务器，在等待应用服务器的处理结果返回到请求的客户端

yg

异步串行