架構設計：生產者/消費者模式 第4頁：注意事項

順便補充幾個注意事項，大夥兒留意一下：

    一、對stdio進行讀寫操做是以阻塞方式進行。好比管道中沒有數據，消費者進程的讀操做就會一直停在哪兒，直到管道中從新有數據。

    二、因爲stdio內部帶有本身的緩衝區（這緩衝區和管道緩衝區是兩碼事），有時會致使一些不太爽的現象（好比生產者進程輸出了數據，但消費者進程沒有當即讀到）。具體的細節，大夥兒能夠看"這裏"。

    ◇SOCKET（TCP方式）

    基於TCP方式的SOCKET通信是又一個相似於隊列的IPC方式。它一樣保證了數據的順序到達；一樣有緩衝的機制。並且這玩意兒也是跨平臺和跨語言的，和剛纔介紹的shell管道符方式相似。

    SOCKET相比shell管道符的方式，有啥優勢捏？主要有以下幾個優勢：

    一、SOCKET方式能夠跨機器（便於實現分佈式）。這是主要優勢。

    二、SOCKET方式便於未來擴展成爲多對一或者一對多。這也是主要優勢。

    三、SOCKET能夠設置阻塞和非阻塞方法，用起來比較靈活。這是次要優勢。

    四、SOCKET支持雙向通信，有利於消費者反饋信息。

    固然有利就有弊。相對於上述shell管道的方式，使用SOCKET在編程上會更復雜一些。好在前人已經作了大量的工做，搞出不少SOCKET通信庫和框 架給大夥兒用（好比C++的ACE庫、Python的Twisted）。藉助於這些第三方的庫和框架，SOCKET方式用起來仍是比較爽的。因爲具體的網 絡通信庫該怎麼用不是本系列的重點，此處就不細說了。

    雖然TCP在不少方面比UDP可靠，但鑑於跨機器通信先天的不可預料性（好比網線可能被某傻X給拔錯了，網絡的忙閒波動可能很大），在程序設計上咱們仍是 要多留一手。具體該如何作捏？能夠在生產者進程和消費者進程內部各自再引入基於線程的"生產者／消費者模式"。這話聽着像繞口令，爲了便於理解，畫張圖給 大夥兒瞅一瞅。

    這麼作的關鍵點在於把代碼分爲兩部分：生產線程和消費線程屬於和業務邏輯相關的代碼（和通信邏輯無關）；發送線程和接收線程屬於通信相關的代碼（和業務邏輯無關）。

    這樣的好處是很明顯的，具體以下：

    一、可以應對暫時性的網絡故障。而且在網絡故障解除後，可以繼續工做。

    二、網絡故障的應對處理方式（好比斷開後的嘗試重連），隻影響發送和接收線程，不會影響生產線程和消費線程（業務邏輯部分）。

    三、具體的SOCKET方式（阻塞和非阻塞）隻影響發送和接收線程，不影響生產線程和消費線程（業務邏輯部分）。

    四、不依賴TCP自身的發送緩衝區和接收緩衝區。（默認的TCP緩衝區的大小可能沒法知足實際要求）

    五、業務邏輯的變化（好比業務需求變動）不影響發送線程和接收線程。

    針對上述的最後一條，再多囉嗦幾句。若是整個業務系統中有多個進程是採用上述的模式，那或許能夠重構一把：在業務邏輯代碼和通信邏輯代碼之間切一刀，把業 務邏輯無關的部分封裝成一個通信中間件（說中間件顯得比較牛X :-）。若是大夥兒對這玩意兒有興趣，之後專門開個帖子聊。