谈谈你接触的通讯程序的模型

gvim

我觉得多进程也是一个可以考虑的设计方向，很多时候，比多线程优势更大。线程的优势在于调度和资源量，问题在大量多线程系统本身的复杂和调试的困难。
两个实例：1 是postgresql的服务模型，进程+shared mem。共享内存只处理全局状态，每一个进程自我处理资源，现在大部分OS的任务切换性能不在是瓶颈。代码很清晰，性能也很高，网上有个图，可以看看。 不好的一点是内存消耗量稍大。如果需要控制进程数量，一般前面有连接池。
2 是基于actor模型的通讯方式，如erlang，(虽然此进程非彼进程，但是实质是一样的"进程”)众所周知的是它的扩展性和分布特性。
另外，每进程的耦合较低，如果不需要处理事务的话，我更倾向于进程，这样可以在适当的时候轻松的把计算分布到其它物理资源上处理(比如erlang)。

我做的关乎server的设计几乎是这个模式的。

gvim

回复 10# duanjigang


个人觉得既然是讨论模型的话，还是需要界定模型适用的领域，模型的解决方案，模型解决的问题，模型具有那些好的非功能性特性，模型的缺点，和其它模型的比较等等。
就像<design pattern>讨论的那样。

duanjigang

我觉得多进程也是一个可以考虑的设计方向，很多时候，比多线程优势更大。线程的优势在于调度和资源量，问题 ...
gvim 发表于 2011-01-02 20:03

    能说说多进程的任务是怎么划分的吗？呵呵，数据通讯，还有处理怎么划分的。

duanjigang

回复  duanjigang


个人觉得既然是讨论模型的话，还是需要界定模型适用的领域，模型的解决方案，模型解 ...
gvim 发表于 2011-01-02 20:23

    嗯，对的，我想从具体的引用谈起，可能更容易讨论起来，而后再把这些模型或者说程序的写法就行比较和总结

gvim

回复 13# duanjigang


回归到你给出的第一种图，不过线程换成进程。
我过去倾向于用线程，但是尝试很多之后设计和调试都随着状态或功能越复杂而越复杂，再加上我个人目标领域的关键约束不在内存上，并且感谢现代操作系统，进程和线程切换的代价已经十分靠近，所以慢慢回归到最简单的方式，现在看来真是越简单越美。直到了解了erlang的处理模式之后，更加深了这个认识。

leiing

楼主都是用长连接吗？
长连接和短连接应该怎么选？如网游服务器，IM服务器？

duanjigang

回复  duanjigang


回归到你给出的第一种图，不过线程换成进程。
我过去倾向于用线程，但是尝试很多之 ...
gvim 发表于 2011-01-02 22:16

    呵呵，请教一个问题，多线程，多进程，相当于单线程有什么优势？通讯性能更高？还是程序的处理逻辑更简单？givm熊能否说点详细的感受。谢谢
如果用单线程的话，都不需要进程的切换。

duanjigang

楼主都是用长连接吗？
长连接和短连接应该怎么选？如网游服务器，IM服务器？
leiing 发表于 2011-01-03 00:21

    惭愧，一提到长连接和短连接，我都有些含糊，不知道你说得是不是开发人员主动控制的连接方式。
比如长连接就是连接上目标主机后一直不断开？短连接就是通讯完成后关闭连接，下次事务再次连接？
如果是这样的话，我一般的选择就是，如果通讯很频繁，而且1对N的N不是特别大的话,就长连接，如果通讯周期很长，比如5分钟传输一次数据，搞成短连接最好吧。
这是个人的一点看法，不知对否？
我们目前接触到的情况是1对8的连接到1对300的连接，都用的恒久连接。因为几乎每分钟内都有数据传输。

dreamice

到目前为止，提到了两种模型，欢迎大家积极拍砖讨论喔。
关于select 和epoll等模型，欢迎熟悉的朋友积极发 ...
duanjigang 发表于 2011-01-02 19:12

    有空了只要没人抢先的话我总结，呵呵
研究了有一段时日了:wink:

duanjigang

有空了只要没人抢先的话我总结，呵呵
研究了有一段时日了
dreamice 发表于 2011-01-03 13:31

    老江赶紧整啊，我最近读别人的代码，select写的，还不错。epoll这块还没多少经验，新版开张，你要多多支持喔。
等咱把这些可能的模型都列出来，总结完了，再发起个实践活动，做下性能和易用性的测试。久而久之，就能形成一些稳定的模型供人试用了