架构设计：生产者/消费者模式 第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 :-）。若是大伙儿对这玩意儿有兴趣，之后专门开个帖子聊。