架構設計：生產者/消費者模式 第2頁：如何肯定數據單元

費了這麼多口水，但願原先不太瞭解生產者／消費者模式的同窗可以明白它是怎麼一回事。而後在下一個帖子中，咱們來講說如何肯定數據單元。

    另外，爲了方便閱讀，把本系列帖子的目錄整理以下：

    一、如何肯定數據單元

    二、隊列緩衝區

    三、隊列緩衝區

    四、雙緩衝區

    五、......

    [1]：如何肯定數據單元？

    既然前一個帖子已經搞過掃盲了，那接下來應該開始聊一些具體的編程技術問題了。不過在進入具體的技術細節以前，我們先要搞明白一個問題：如何肯定數據單元？只有把數據單元分析清楚，後面的技術設計纔好搞。

    ★啥是數據單元

    何謂數據單元捏？簡單地說，每次生產者放到緩衝區的，就是一個數據單元；每次消費者從緩衝區取出的，也是一個數據單元。對於前一個帖子中寄信的例子，咱們能夠把每一封單獨的信件當作是一個數據單元。

    不過光這麼介紹，太過於簡單，無助於大夥兒分析出這玩意兒。因此，後面我們來看一下數據單元須要具有哪些特性。搞明白這些特性以後，就容易從複雜的業務邏輯中分析出適合作數據單元的東西了。

    ★數據單元的特性

    分析數據單元，須要考慮以下幾個方面的特性：

    ◇關聯到業務對象

    首先，數據單元必須關聯到某種業務對象。在考慮該問題的時候，你必須深入理解當前這個生產者／消費者模式所對應的業務邏輯，纔可以做出合適的判斷。

    因爲「寄信」這個業務邏輯比較簡單，因此大夥兒很容易就能夠判斷出數據單元是啥。但現實生活中，每每沒這麼樂觀。大多數業務邏輯都比較複雜，當中包含的業務對象是層次繁多、類型各異。在這種狀況下，就不易做出決策了。

    這一步很重要，若是選錯了業務對象，會致使後續程序設計和編碼實現的複雜度大爲上升，增長了開發和維護成本。

    ◇完整性

    所謂完整性，就是在傳輸過程當中，要保證該數據單元的完整。要麼整個數據單元被傳遞到消費者，要麼徹底沒有傳遞到消費者。不容許出現部分傳遞的情形。

    對於寄信來講，你不能把半封信放入郵筒；一樣的，郵遞員從郵筒中拿信，也不能只拿出信的一部分。

    ◇獨立性

    所謂獨立性，就是各個數據單元之間沒有互相依賴，某個數據單元傳輸失敗不該該影響已經完成傳輸的單元；也不該該影響還沒有傳輸的單元。

    爲啥會出現傳輸失敗捏？假如生產者的生產速度在一段時間內一直超過消費者的處理速度，那就會致使緩衝區不斷增加並達到上限，以後的數據單元就會被丟棄。如 果數據單元相互獨立，等到生產者的速度降下來以後，後續的數據單元繼續處理，不會受到牽連；反之，若是數據單元之間有某種耦合，致使被丟棄的數據單元會影 響到後續其它單元的處理，那就會使程序邏輯變得很是複雜。

    對於寄信來講，某封信弄丟了，不會影響後續信件的送達；固然更不會影響已經送達的信件。

    ◇顆粒度

    前面提到，數據單元須要關聯到某種業務對象。那麼數據單元和業務對象是否要一一對應捏？不少場合確實是一一對應的。

    不過，有時出於性能等因素的考慮，也可能會把N個業務對象打包成一個數據單元。那麼，這個N該如何取值就是顆粒度的考慮了。顆粒度的大小是有講究的。太大 的顆粒度可能會形成某種浪費；過小的顆粒度可能會形成性能問題。顆粒度的權衡要基於多方面的因素，以及一些經驗值的考量。

    仍是拿寄信的例子。若是顆粒度太小（好比設定爲1），那郵遞員每次只取出1封信。若是信件多了，那就得來回跑好多趟，浪費了時間。

    若是顆粒度太大（好比設定爲100），那寄信的人得等到湊滿100封信纔拿去放入郵筒。假如平時不多寫信，就得等上好久，也不太爽。

    可能有同窗會問：生產者和消費者的顆粒度可否設置成不一樣大小（好比對於寄信人設置成1，對於郵遞員設置成100）。固然，理論上能夠這麼幹，可是在某些狀況下會增長程序邏輯和代碼實現的複雜度。後面討論具體技術細節時，或許會聊到這個問題。

    好，數據單元的話題就說到這。但願經過本帖子，大夥兒可以搞明白數據單元究竟是怎麼一回事。下一個帖子，我們來聊一下「基於隊列的緩衝區」，技術上如何實現。