Unix C 网络多进程框架设计

zhitenglin

最近我在设计一套Unix C的多进程核心框架，但是遇到一个性能问题，想请教一下，CU的高手，呵呵。。。
事情是这样子的，我的设计目标是同一时刻可以达到1万的并发请求以上。。。。
就Unix Server这边，我现在是select监听本机一个IP和Port，每来一个请求，就fork一个通信子进程，accept到一个socket，然后这个子进程
负责接收数据，然后把数据通过一个共享内存队列发往同一台机器上面的服务组进程，服务组进程从共享内存队列中取到请求包后，对数据库做操作,select之类的，
完后，把返回包，也打回共享内存队列，通信进程然后从共享内存队列把返回包拿出来，发往accept到的socket客户端，完成后退出。。。
流程就这样子。。。。。
服务组那些进程是固定的，但是通信进程这边，每处理完一个请求，就消亡了，要是同一时刻来1万的请求，就有1万个通信进程产生和消亡，听网上说，这样子，系统性能上不去。
所以就想到如下方案：
先fork一定数目的通信进程，如3000，然后每个通信子进程，都在accept监听，来请求后，处理完后，通信进程子进程也不退出，这样就避免了进程开销，再开一个监控进程，如果
负荷太大，再fork一些进程，进调度一下。。。跟上面的区别是，上面是一个进程在监听，下面的方案是，多个子进程在监听。。
但是网上也提到了“惊群"问题，所以只能加一个信号量来进行锁操作，同一时刻只有一个通信子进程在阻塞在accept上面，其它子进程则阻塞在信号量的P操作上面。

上面的方案似乎解决了性能问题，但是不太确定这样子还有没有问题。。。
本人工作不久，接触的项目不多，所以来这里发个帖子，看有没有在金融，电信，移动，保险行业做Unix C的同仁，根据你们的经验，怎么样才能把多进程调度做好，做得相当高效，
请赐教!


Unix C 网络多进程框架设计－负载均衡
这个问题，也是不太确定，只是一种猜疑，如果现在有一台机器，一张网卡，每秒过来1万个请求，跟同样一台机器，两张一样的网卡（跟前面一样），然后叫客户端那边，两张网卡，每秒各请求5000个，但是两种方案，都是同一个程序在监听，同样数目的请求。这样子的对比下，性能有没有大一点的区别？望有经验的高手，赐教啊。。。
虽然现在的网卡，动不动是千M的，但是两张网卡，会不会好一点？打个比喻就是，一张网卡通信量在100M，跟两张网卡各自50M的下载，这样子，效率会不会高一点。。。。
不知道一般那些高负荷的请求，是怎么样的做负载均衡的？假设机器数目都是一样的。。。难道只是简单地把请求分发到不同的服务器？

大梦

Unix C方面我也只是略知一二;
我觉得你要自己从头去设计估计工作量还是比较大,特别是数据传输的问题,要保证数据仅成功的传一次,一般的系统能撑住你fork出10000进程估计很难吧!
可以考虑采用消息类的中间件!

mike79

要支持每秒10K次网卡中断？
数据库要保持10K个长连接？每个数据库客户端进程5M内存总会有吧？就是说什么事情都不作就要用掉50G内存？

[ 本帖最后由 mike79 于 2010-1-17 00:12 编辑 ]

flymouses

普通单CPU机器多进程fork一般每秒<50个还行，再高估计fork时间比处理时间还累
另外，就是用进程池也吃不消这个10000每秒的请求。

所以不能简单用一台机器来处理，而且这个压力一台机器翘了，这个损失也大

起码用分布式处理，至于成熟中间件，应该只能做后台处理不适合前台接入
=========
目前主要问题是前台接入（后台可以快速排队处理），这个如果是简单socket,
那就自己写程序吧，但最好不要有会话保留的方式，用UDP

zhitenglin

我现在也不是1秒内fork1万个进程来接收请求，而是预先fork了几千个子进程等待，网络监听这一部分，也不是说每秒得处理1万个请求（最高峰会一下子来10000个请求），因为子进程得等待服务组处理进程，处理完请求，把返回包返回给通信进程，由通信进程返回给客户端，就是说，同一时刻，最多有10000个请求在处理，这个过程，一般10s以内处理理完毕。。。然后处理后面来的请求，中间有完成的，就继续接纳新的请求进程处理，就是说“同一时候，最大有10000个进程在处理“。


10000个请求就那么麻烦，那么那些百万级请求，怎么处理的？使用线程？
像那些网页服务器，上面的apache等网页服务器，可以处理百万级的请求啊？

反正现在，我的调度方式，就是先fork一个minnumber的通信子进程，会有一个监控进程，如果请求太多，会动态fork多一些通信子进程，但是最多不会超过maxnumber进程。

很想知道，那些银行的系统怎么弄的？分布式？怎么个分布式法，有没有有这方面的经验的，讨论一下啊。。。。
银行那些一秒肯定不下1万请求吧。。。。

cskyrain

“10000个请求就那么麻烦，那么那些百万级请求，怎么处理的？使用线程？”
不是线程的问题，百万级的也绝对不是一台能搞的定的，而且web服务器处理的数据都比较简单，你这个处理的过程要复杂些。
converse版主是这方面的牛人，等他来讲讲吧，还有你可以看看converse的blog
http://www.cppblog.com/converse/archive/2010/01.html

nanduo

单服务器1w的并发量肯定可以，单进程epoll就行了，后台工作进程可以是多个，中间用消息队列通信。
服务器架构可以看看UNP，里面都有

[ 本帖最后由 nanduo 于 2010-1-17 21:54 编辑 ]

sunlan

其实基于TCP的中间件基本上都是这样干的。
一般有几种形式：
1）单守护、实时调用。即一个侦听服务，在有请求时调用服务进程处理，服务程序处理完毕后退出。
2）单守护、预起服务。即在启动侦听时同时启动多个服务，有交易请求后分配任务至某个进程。Tuxedo就是典型的代表。
前者实现简单、后者效率相对较高。
其实不管用哪种模式，想同时并发数千个处理进程对系统都是一种考验。尤其是在预起服务时，即使没有任何交易请求，几千个进程也会消耗大量的系统资源。这个能在sar的sys项中看出来。

zhitenglin

向大家道个歉，上周刚好换工作，到了新单位，工作现在是客户现场，不能上网，唉。。。
加上女朋友用U盘带了个小家伙回来，把我电脑给搞了，唉。。。
回复慢了，还得多谢各位回复啊，呵呵。。。

zhitenglin

原帖由 大梦 于 2010-1-17 00:09 发表
Unix C方面我也只是略知一二;
我觉得你要自己从头去设计估计工作量还是比较大,特别是数据传输的问题,要保证数据仅成功的传一次,一般的系统能撑住你fork出10000进程估计很难吧!
可以考虑采用消息类的中间件!

消息类的中间件，以前没有接触过，最近公司有个二期的项目，要使用到IBM 的MQServices，消息类中间件，IBM这个产口是跨平台的。。。其实，这个东西，就是做了网络通讯这一块，里面也肯定使用到了socket多进程监听和调度的东西，用它剩下的工作是比较简单了，对企业开发来说是有好处，不过现在本人想自己搞一个轻量级的socket监听多进程的服务内核，所以不打算使用它。。。呵呵。

[ 本帖最后由 zhitenglin 于 2010-1-30 14:33 编辑 ]