讨论一个服务器的设计方案

cookis

原帖由 学与思 于 2010-1-26 10:18 发表
我看过一个网游的连接服务器，它的任务也是转发数据，但我怀疑这个转发服务器的效率，比如epoll_wait回来有2万个socket可读那么串行的去读，读到最后一个时是不是时间已经过去了很多了，不会存在严重延迟吗？而 ...

1. 不要低估网络的能力
2. 不是说2W个socket的数据读完了，才开始给第一个socket发送数据，这个是同时进行的，异步处理

zsniper

这种设计不是很合理。

连接服务器(gateway)一般都采用多个并发的网络层，1个逻辑层，也就是说多个IO线程，1个工作线程。

楼主可以使用多个IO线程，每个线程管理一定量的描述符，线程之间用管道进行描述符的传递，可以参考memcached的模式。

benjiam

召唤构架师们。 这里有现成的例子 让你们大显身手呢。


memached 也是单线程的吧。  完全只有一个线程。
在epoll 这种模型下 网络层只需要单线程就可以了。 你的问题是 拿到了数据 处理起来时间可能比较多，所以需要一个消息队列。
将io数据解包后传给逻辑层。 逻辑层需要发送的数据再发回给io线程。

zsniper

哥们，去看看代码吧，memcached是多个IO线程的。

在多核的机器上，多个IO线程肯定要比单个IO线程要高效，当然也要看你的设计。

在代理服务器上，逻辑层处理时间很少，只需要转发给其他的描述符即可。

所以我觉得应该是多个IO层，来处理大量的IO，单个逻辑线程去确定到底转发给哪个描述符。

PS：
epoll只是在管理描述符事件，而且只是管理很多空闲的描述符上很有优势。目前gateway不光是要管理大量的描述符，而且需要进行大量的网络IO。
所以多并发的IO线程还是有必要的，并且在多核的服务器上，还是有一定的优势，当然设计的不好，不一定能带来很好的性能。

[ 本帖最后由 zsniper 于 2010-1-26 14:04 编辑 ]

benjiam

sorry, 这个源码没看过。 记得原来看过一个分析源码的文章。里面提到是单线程。

网上搜到的内容是
程序基于libevent，使用单线程 event-driven 的风格（1.2.0 版本，1.2.2 版本已经开始使用多线程）

我说是单线程 这个抱歉。  但是就我现在用到的情况看 epoll 单线程的收发速度也是没有问题的。可以说瓶颈不在这个上面。

zsniper

收发速度就和epoll无关了。

我开发的项目大部分也是单个IO线程，但前段时间做过测试，单IO线程的确没有多IO线程来的高效。

就楼主目前的项目需求而言，逻辑层更加没有瓶颈了，所以我才建议楼主用多IO线程的框架。

gczh1006

12L 已经将整个系统的逻辑划分的很清楚了

唯一要确定的是IO线程的个数，单个线程的效率在多核CPU上效率不够，这点大家都很认同。但是不代表IO线程越多越好，在LZ这样的应用之上，处理的逻辑基本上就是一个数据转发，所以，按CPU的个数来配置IO线程的数量就差不多了。

BTW: 流媒体服务器Darwin貌似就是这样设计的。

chary8088

一个进程能开两万多个线程吗？？？？？？？？？？

zsniper

开2W个线程，你会死的很快。

多IO线程不是说开这么多，IO线程一般==CPU的核数。

多IO线程不会比单个IO线程的效率高多少，很多情况下瓶颈不在IO上，而在逻辑层。

但你的应用逻辑层比较简单，所以我才建议你使用多IO线程。

[ 本帖最后由 zsniper 于 2010-1-26 15:58 编辑 ]

lypat2008

要7*24小时? 业务嘛?那只能靠群集冗余了,研发是解决不了这个问题的.