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

BetonArmEE

原帖由 yulihua49 于 2009-11-14 12:57 发表

大多数应用服务器不需要进程间通信。或避免进程间通信，利用数据库交换信息。

在这个条件下，如果是UNIX/linux环境，采用多线程没必要。

多线程比多进程性能高？误导！
应该说，多线程比多进程成本低， ...

你的话很有借鉴性，谢谢 ^_^

请问银行后台运行平台架构如何设计？或者有什么思路？
我最近在看apache源代码，想把它的前端拿过来用

[ 本帖最后由 BetonArmEE 于 2009-11-14 23:03 编辑 ]

asdmonster

就这样还搞系统设计呢？典型的架构和技术细节纠缠不清，系统迟早会成为一团乱麻，即使做出来了也一直行走在崩溃的边缘。

cugb_cat

通信程序是一个进程，业务逻辑是一个进程，二者使用共享内存，完全不受干扰，我们的很多程序架构是这样的。

yulihua49

原帖由 BetonArmEE 于 2009-11-14 22:59 发表


你的话很有借鉴性，谢谢 ^_^

请问银行后台运行平台架构如何设计？或者有什么思路？
我最近在看apache源代码，想把它的前端拿过来用

不知你们对平台或架构的需求是什么。我通常是做OLTP架构的。

BetonArmEE

原帖由 yulihua49 于 2009-11-15 14:08 发表

不知你们对平台或架构的需求是什么。我通常是做OLTP架构的。

AIX + oracle + c
银行交易后台实时处理
TCP或其它通讯方式接入，调用相应的交易处理程序处理，通讯实时返回。这是平台开发人员要做的事情。
交易处理程序按业务分类交易分类由若干组开发人员开发，被平台调用。这是交易处理程序开发人员要做的事情。

yulihua49

原帖由 BetonArmEE 于 2009-11-15 15:15 发表


AIX + oracle + c
银行交易后台实时处理
TCP或其它通讯方式接入，调用相应的交易处理程序处理，通讯实时返回。这是平台开发人员要做的事情。
交易处理程序按业务分类交易分类由若干组开发人员开发，被平 ...

我们的系统是：关键业务以TUXEDO接入，数据库oracle。客户端是JAVA ＋ jolt。部分其它服务B/S，B/S/S模式。
即WEB服务器向TUXEDO提服务请求。服务器安全认证由平台组提供（如login，logout模块），业务软件由开发组编写。
应用服务分服务接入层（service)，业务逻辑层（app)，数据存取层（Dao)。
系统采用多进程模式，TUXEDO事先启动若干进程守候服务，它们打开了数据库。因此，每次服务请求无须启动进程、认证、打开数据库等操作，服务效率是非常高的。

[ 本帖最后由 yulihua49 于 2009-11-15 15:38 编辑 ]

peidright

-。-不太懂。
照你的说法，只能多进程，每个进程派生出一定数量线程来缓解了。

思一克

原帖由 yulihua49 于 2009-11-14 12:57 发表

大多数应用服务器不需要进程间通信。或避免进程间通信，利用数据库交换信息。

在这个条件下，如果是UNIX/linux环境，采用多线程没必要。

多线程比多进程性能高？误导！
应该说，多线程比多进程成本低， ...

基本同意。
LINUX上，多线程有些是画蛇添足的东西。
多线程，牺牲系统的优美和鲁棒性，换来的东西很少很少。
调度和多进程一样。内存节省一点，但程序失去的是容错能力（就是一条鱼能坏了一锅汤）。

system888net

利用数据库交换信息,前提是对交换的效率要求不高.

wishel

原帖由 BetonArmEE 于 2009-11-14 22:58 发表


银行后台系统，几个能力强的人写平台程序，大多数业务强的写交易程序

莫非偌大的银行后台你想一个人写？

抬杠么？

莫非诺大的公司只有一个人能写好程序？

[ 本帖最后由 wishel 于 2009-11-15 18:40 编辑 ]