架构设计：生产者/消费者模式 第2页：如何肯定数据单元

费了这么多口水，但愿原先不太了解生产者／消费者模式的同窗可以明白它是怎么一回事。而后在下一个帖子中，咱们来讲说如何肯定数据单元。

    另外，为了方便阅读，把本系列帖子的目录整理以下：

    一、如何肯定数据单元

    二、队列缓冲区

    三、队列缓冲区

    四、双缓冲区

    五、......

    [1]：如何肯定数据单元？

    既然前一个帖子已经搞过扫盲了，那接下来应该开始聊一些具体的编程技术问题了。不过在进入具体的技术细节以前，我们先要搞明白一个问题：如何肯定数据单元？只有把数据单元分析清楚，后面的技术设计才好搞。

    ★啥是数据单元

    何谓数据单元捏？简单地说，每次生产者放到缓冲区的，就是一个数据单元；每次消费者从缓冲区取出的，也是一个数据单元。对于前一个帖子中寄信的例子，咱们能够把每一封单独的信件当作是一个数据单元。

    不过光这么介绍，太过于简单，无助于大伙儿分析出这玩意儿。因此，后面我们来看一下数据单元须要具有哪些特性。搞明白这些特性以后，就容易从复杂的业务逻辑中分析出适合作数据单元的东西了。

    ★数据单元的特性

    分析数据单元，须要考虑以下几个方面的特性：

    ◇关联到业务对象

    首先，数据单元必须关联到某种业务对象。在考虑该问题的时候，你必须深入理解当前这个生产者／消费者模式所对应的业务逻辑，才可以做出合适的判断。

    因为“寄信”这个业务逻辑比较简单，因此大伙儿很容易就能够判断出数据单元是啥。但现实生活中，每每没这么乐观。大多数业务逻辑都比较复杂，当中包含的业务对象是层次繁多、类型各异。在这种状况下，就不易做出决策了。

    这一步很重要，若是选错了业务对象，会致使后续程序设计和编码实现的复杂度大为上升，增长了开发和维护成本。

    ◇完整性

    所谓完整性，就是在传输过程当中，要保证该数据单元的完整。要么整个数据单元被传递到消费者，要么彻底没有传递到消费者。不容许出现部分传递的情形。

    对于寄信来讲，你不能把半封信放入邮筒；一样的，邮递员从邮筒中拿信，也不能只拿出信的一部分。

    ◇独立性

    所谓独立性，就是各个数据单元之间没有互相依赖，某个数据单元传输失败不该该影响已经完成传输的单元；也不该该影响还没有传输的单元。

    为啥会出现传输失败捏？假如生产者的生产速度在一段时间内一直超过消费者的处理速度，那就会致使缓冲区不断增加并达到上限，以后的数据单元就会被丢弃。如 果数据单元相互独立，等到生产者的速度降下来以后，后续的数据单元继续处理，不会受到牵连；反之，若是数据单元之间有某种耦合，致使被丢弃的数据单元会影 响到后续其它单元的处理，那就会使程序逻辑变得很是复杂。

    对于寄信来讲，某封信弄丢了，不会影响后续信件的送达；固然更不会影响已经送达的信件。

    ◇颗粒度

    前面提到，数据单元须要关联到某种业务对象。那么数据单元和业务对象是否要一一对应捏？不少场合确实是一一对应的。

    不过，有时出于性能等因素的考虑，也可能会把N个业务对象打包成一个数据单元。那么，这个N该如何取值就是颗粒度的考虑了。颗粒度的大小是有讲究的。太大 的颗粒度可能会形成某种浪费；过小的颗粒度可能会形成性能问题。颗粒度的权衡要基于多方面的因素，以及一些经验值的考量。

    仍是拿寄信的例子。若是颗粒度太小（好比设定为1），那邮递员每次只取出1封信。若是信件多了，那就得来回跑好多趟，浪费了时间。

    若是颗粒度太大（好比设定为100），那寄信的人得等到凑满100封信才拿去放入邮筒。假如平时不多写信，就得等上好久，也不太爽。

    可能有同窗会问：生产者和消费者的颗粒度可否设置成不一样大小（好比对于寄信人设置成1，对于邮递员设置成100）。固然，理论上能够这么干，可是在某些状况下会增长程序逻辑和代码实现的复杂度。后面讨论具体技术细节时，或许会聊到这个问题。

    好，数据单元的话题就说到这。但愿经过本帖子，大伙儿可以搞明白数据单元究竟是怎么一回事。下一个帖子，我们来聊一下“基于队列的缓冲区”，技术上如何实现。