单进程多线程服务器存在这样的弊端

houhulou

看了各位牛人的神论 受益匪浅, 我前几天做了SOCKET通讯方面的项目, 我的做法是 :
创建SOCKET 监听->ACCEPT一个 后 鉴权和连接数检查->子线程->主线程查看有没有退出的SOCKET连接 维护一个SOCKET信息的list
    子线程->创建两个子线程  三个线程一个用来接收, 一个用来 发送消息包, 一个用来发送心跳包
用的SELECT + 阻塞, 我实在搞不明白非阻塞SOCKET哪里好, 阻塞和非阻塞 只有 缓冲区满的时候才有分别吧 , 是不是缓冲区满的时候,阻塞在那里 站着茅坑不拉屎啊... 既然反正都要发送信息 况且我那个线程只用来发送信息, 还不如挂在那里 等到发送完 .
至于和后面的业务进程通讯 用的共享内存,
最开始 我用多进程做的 , 发现真连起来进程太多 不爽  就改成支持多线程 至于性能 嘿嘿 我没测试过
感觉比决捆饶人的是 如何制定通讯协议做到不丢数据

houhulou

阻塞的时候还会站着CPU 如果非阻塞可以让出CPU 应该这个吧?

knift

多进程还是多线程和业务有关。。像http这种连接与连接之间没有逻辑的应用，用多进程可以作到无锁，所以高并发，nginx,lighttpd都玩的是这一套。。。反之，进程间数据共享免不了加入锁，效率未必就高。

QQGame的数百万级同时在线用户，连接接入层的connector也是用epoll单线程。

houhulou

楼上的 线程共享就不要锁了

如戏

关注中

mantiser

这是一个系统可靠性问题。代码当然不允许有缺陷，但是不等于在一定时间内可以挖完。设计可靠系统可以暂时规避问题，保证业务通常。

建议楼主不要把多进程设计就一定要和多线程当作异步来用。可以把进程当作备用进程用，加上利用守护进程。一个进程core了备用进程可以临时接替。

bsdc

mark下

BetonArmEE

今天偶然翻出旧帖。
平台自上线以来一直稳定高效运行至今。
我最后采用的进程模型是 管理进程+工作进程组（accept临界区、周期性重建的半长进程），此外还实现了 三层超时控制机制、在线配置重载、软负载均衡、远程管理、栈式堆内存池、编译配置映像、三层密钥体系等技术，压测单台服务器平均500＋t/s（30台客户端吃不消了，应该还没到最大值），目前生产日均150万笔交易/每台服务器。

感谢大家当年热烈的讨论，给了我丰富的参考价值和设计帮助，很多朋友还和我在其它渠道友好的做了更深入的探讨，谢谢你们 ^_^

yulihua49

BetonArmEE 发表于 2009-11-13 14:33
最近搞高性能服务器设计，在unix平台上用c写
设计了在单进程中使用线程池模型的通讯架构，后端装载动态链接 ...

这个问题我们基本解决了。
第一个办法，提供通用的可靠的工具集，由经验的写，业务逻辑尽量使用工具集，避免自己写类似代码。这个很成功，很短时间由一帮学生弄出很可靠的系统。
第二个办法，正是你上边的办法，也是TUXEDO的办法。
即：主服务器采用PPC（Process Per Connection)模式，外配交易管理器。
成千上万的客户端连接到交易管理器，它对主服务器建立有限个连接（池），在二者之间转发消息。


在此之后我也有个思想转变，这两年做了大量多线程并行处理的项目，现在我不反对多线程了。
在很多处理中多线程还是具有很多优势的。

例如典型的OLTP服务器，每个进程都要有一个数据库连接。每台主机常常几十个进程，几十个连接同时访问数据库，在引擎内部大混战，严重影响效率。

采用多线程服务器，+数据库连接池，每个主机4-5个连接，几十个线程排队（竞争有序化了）共享数据库连接，性能明显提高。

现在否定了原来的我，我的多线程系统已经能够实现高吞吐量高并发的应用，确实比多进程性能高很多。
并不是进程、线程调度差别，而是内部资源共享方式引起的。一些常用数据在内存建表，多线程共享，这在多进程很难弄。

yulihua49

BetonArmEE 发表于 2009-11-16 20:28
我目前开发环境也是c，不是c++
请问数据库操作（用的是oracle）用OCI好还是嵌入式SQL好？从速度方面、 ...

居然当年就回了这个帖子。
最近才做的实验。
相同的数据库和数据，进行简单的数据unload测试，存粹的读数据库写文件，包括一个通用处理，可以任何表。OCI比PROC快，大约是它的2.5倍。而且CPU耗时少得多。