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

BetonArmEE

原帖由 redor 于 2009-11-15 19:12 发表



我估计apache也是因为这个原因才多进程的， 另外chrome好像也是因为这个才多进程方式了


不过感觉是很奇怪的理由

apache1.3就是用多进程＋accept锁通讯模型的，不知道2.2是怎么样的？刚买了本分析apache2源代码的书，明天到了看看

BetonArmEE

原帖由 unixpm 于 2009-11-16 09:25 发表
我以前也在某通信设备商做过电信系统后台的开发,
纯业务和底层的通信之类的肯定是要分层的，
纯业务的程序员最好不要让他使用c, c++之类的语言(一般都是新兵蛋子)，最好能够自己开发一种二次开发语言，
并将 ...

开发二次语言我觉得太繁琐了，一般写银行后台的c表达也不会差到哪里去
核心系统对速度要求很高，当然，稳定性是最重要的

BetonArmEE

原帖由 unixpm 于 2009-11-16 11:24 发表
呵呵，是啊，这些都是个大系统，分工明确，需要很多东西支持。
而且业务IDE还支持调试，单步跟踪等复杂功能（跨机器），
以前不觉得怎么样，后来想想还是挺牛的，呵呵

搞个IDE花费成本太高，我觉得只要平台开发人员设计的好，交易开发人员可以少写很多代码，日志系统完善，除错也很方便的

zhoubug

如果有楼主这个担心 apache的模型正是可以借鉴的解决方案，无论prefork还是后来引入多线程（仍然是单进程内部的多线程）apache保留有
多进程的安全保障。所以不论是php模块，python等等或者你自己写的模块 某次意外崩溃 不会影响整体服务质量，但这种模型的一个
特点就是单个请求的严格业务分离，几乎不存在共享数据需要同步的情况（即使有也有方案可以解决），这点可能和一些行业软件的需求有点差别，但也有类似的需求存在，
比如电信BOSS系统，对于单个工单都是为单个用户服务，到了后台网管部分这个工单的处理和别的用户的请求是没有数据关联。互联网开发的常用
技术和其他电信，金融等行业应该是有很多技术上可以借鉴的地方，不过由于从业人员的分离这方面体现还不太明显。

BetonArmEE

原帖由 zhoubug 于 2009-11-16 12:58 发表
如果有楼主这个担心 apache的模型正是可以借鉴的解决方案，无论prefork还是后来引入多线程（仍然是单进程内部的多线程）apache保留有
多进程的安全保障。所以不论是php模块，python等等或者你自己写的模块 某次 ...

谢谢 ^_^

zsniper

对你的说法，不敢苟同。

大多数应用服务器不需要进程间通信。或避免进程间通信，利用数据库交换信息 ///// 大多数应用服务器肯定需要不同形式的进程间通信，在多进程环境中，使用共享内存，也需要加锁的。

多线程比多进程成本低，但性能更低。///// 请你拿出准确的测试数据来

另外apache的多进程是与连接相关的 。更多时候的服务器应该避免工作进程或者线程与连接相关。

[ 本帖最后由 zsniper 于 2009-11-16 15:54 编辑 ]

思一克

原帖由 zsniper 于 2009-11-16 15:52 发表
对你的说法，不敢苟同。

大多数应用服务器不需要进程间通信。或避免进程间通信，利用数据库交换信息 ///// 大多数应用服务器肯定需要不同形式的进程间通信，在多进程环境中，使用共享内存，也需要加锁的。
...

进程的通信需要的确不多。
为什么要进程？就是为了隔离的。进程的本质要求是拒绝通信的。
比如银行存取款业务，应该是一个业务（叫一个用户的操作，我对这个不专业）一个进程。不同进程之间在OS级别是彻底隔离的。因此不存在有偷窃，剽窃他人信息的可能。
用多线程实现本质是不可靠的。因为没有达到底层的数据的隔离，操作的隔离。用户之间还能互相影响。一个用户操作坏掉，可能殃及另外用户。

LINUX是用进程实现的线程。线程就是数据内存共享的进程。因此，除了节省一些内存外，无其他速度的优势。
进程本身也是有共享的。用的是OS级别的一些技术。比如同一个程序作为不同进程运行，代码在内存实际是一份。不重复的。数据有写的时候再用新内存等技术。考虑到这些，线程的存在意义就更低了。

思一克

高性能服务器，负载大了后系统性能下降的原因
不是用进程造成的。
而是进程启动造成的---就是来一个业务现启动一个进程。
对于大量的时间短小的业务，启动进程耽误了时间和空间。

如果用进程守株待兔的工作方式（apache类似的），速度影响就不大了。

yulihua49

原帖由 BetonArmEE 于 2009-11-16 12:36 发表


我想了解的是运行环境的平台系统内部结构。目前听了很多高手的建议，似乎还是用多进程＋accept锁做通讯接入比较好了。报文交换可以用数据库或者共享内存，我个人觉得共享内存应该比较快。

C啊，可以C++但目前是C；

使用几套开源的函数库：sqlora包装OCI，JSON组织数据和通信格式。DAU高级数据库包装器，内含结构模板接口。处理任意结构与数据库、JSON的转换。
就是这个DAU，解决了程序可靠问题，所有数据对象的传送转换都由它进行，彻底杜绝内存使用不当的问题。

[ 本帖最后由 yulihua49 于 2009-11-16 17:54 编辑 ]

BetonArmEE

原帖由 yulihua49 于 2009-11-16 17:50 发表

C啊，可以C++但目前是C；

使用几套开源的函数库：sqlora包装OCI，JSON组织数据和通信格式。DAU高级数据库包装器，内含结构模板接口。处理任意结构与数据库、JSON的转换。
就是这个DAU，解决了程序可靠问题 ...

我目前开发环境也是c，不是c++
请问数据库操作（用的是oracle）用OCI好还是嵌入式SQL好？从速度方面、开发易用性方面等等来讲