談?wù)勀憬佑|的通訊程序的模型

jiang1013nan

回復(fù) 45# 一介村夫


   嗯。沒錯。關(guān)鍵是合適的場景選擇合適的模型，其中一個線程出現(xiàn)問題，一個進(jìn)程都會崩潰。多個進(jìn)程則不會出現(xiàn)同樣的問題，apache就是多個子進(jìn)程干同樣的事情。

jiang1013nan

回復(fù) 47# duanjigang


如果將讀和寫分別放在不同的進(jìn)程中，就意味著server和client至少保持一個連接，代價(jià)是不是太高啦？如果將讀和寫分別放在不同的線程中，只需要保持一個連接。

jiang1013nan

回復(fù) 44# duanjigang


  是的，沒錯。

通訊層就是類似于數(shù)據(jù)中間件，負(fù)責(zé)client與業(yè)務(wù)處理層面的數(shù)據(jù)接受與發(fā)現(xiàn)。如果涉及到udp的話，采用這種方式似乎有些困難額。

jiang1013nan

回復(fù) 46# duanjigang


    我認(rèn)同將通訊和業(yè)務(wù)進(jìn)行分離，通訊只負(fù)責(zé)數(shù)據(jù)的接受；業(yè)務(wù)負(fù)責(zé)處理數(shù)據(jù)，很大情況下，業(yè)務(wù)處理出現(xiàn)崩潰的情況更多一些。

jiang1013nan

回復(fù) 48# swxlion


    64位，8核，16G內(nèi)存

jiang1013nan

該版內(nèi)有很多牛人額。繼續(xù)學(xué)習(xí)，繼續(xù)接受大家的BS哈。

繼續(xù)去找工作哈。

網(wǎng)鬼

拜讀學(xué)習(xí)。。。

logicBaby

多線程。。。一旦core掉就悲劇了。。。。。。

所以我們的都是多進(jìn)程的，而且有專門的維護(hù)進(jìn)程定期監(jiān)控各任務(wù)進(jìn)程的狀態(tài)。

我們的模型很簡單，tcpSvr接到鏈接后派生相應(yīng)的XXXTask進(jìn)程完成請求的功能，完成后推出。或者可以預(yù)先啟動數(shù)個XXXTask進(jìn)程等待tcpSvr的任務(wù)分派。

gvim

多線程。。。一旦core掉就悲劇了。。。。。。

所以我們的都是多進(jìn)程的，而且有專門的維護(hù)進(jìn)程定期監(jiān)控各 ...
logicBaby 發(fā)表于 2011-01-11 23:28

簡單的異常監(jiān)控，如果是unix下的采用父子模式，我目前用的一種監(jiān)控方案是用子進(jìn)程事件來管理，比如user1，user2，SIGCHLD，父進(jìn)程就可以作為各子進(jìn)程的維護(hù)進(jìn)程。這樣不用定期，反正子進(jìn)程有異常了事件就過來了。
當(dāng)然，這樣做是比較粗略的監(jiān)控方式。如果要做精細(xì)監(jiān)控就不合適了。

gvim

呵呵，請教一個問題，多線程，多進(jìn)程，相當(dāng)于單線程有什么優(yōu)勢？通訊性能更高？還是程序的處理邏輯更簡單？givm熊能否說點(diǎn)詳細(xì)的感受。謝謝
如果用單線程的話，都不需要進(jìn)程的切換
duanjigang 發(fā)表于 2011-01-03 10:22

優(yōu)勢不少，劣勢在內(nèi)存上。
一般用途的通訊服務(wù)器必然涉及并發(fā)處理，所以很難看到有單線程的通訊服務(wù)產(chǎn)品。只要涉及并發(fā)，不管是進(jìn)程還是線程都要切換。比較新的unix/linux基本切換開銷相差很小，當(dāng)然并不是說沒有差距。我測過適合我的服務(wù)負(fù)載的吞吐差別不大，PC 4核4G，測試目標(biāo)好像是2000還是3000并發(fā)，記不太清楚了。
摩爾定理也是設(shè)計(jì)上的預(yù)測，如果可以通過加強(qiáng)機(jī)器性能，我寧愿選擇代碼的維護(hù)，擴(kuò)展和進(jìn)程任務(wù)的相對單一性。
就如同用爛的OOP一樣，更多的設(shè)計(jì)增加了層，也增加了復(fù)雜性。當(dāng)然，依據(jù)設(shè)計(jì)對象不同也可能是必須的。