你会不会分布式系统进程间通信？

进程间通信

关于进程间通信，我前前后后写了不下十篇，后来整理成了一两篇，无非是写：shm共享内存、消息队列、管道等方式。但是今天我接触到了另外一种以前确实没有想过的进程间通信方法，我把它讲给我的朋友们听，他们都惊呆了。那就是：TCP实现进程间通信。

本篇不会教你怎么使用TCP，详情请看前言。我们就来聊聊，为什么我们会为这个通信“新”方法而吃惊吧，毕竟也是经历过小风浪的人，是不会因为新奇而有这么大反应。

TCP在进程间通信的优势

首先，就是分布式系统，这点当看到TCP做进程间通信的时候我就想到了。TCP进程间通信可以跨主机，具有伸缩性，把进程分布到不同的服务器上，改改TCP端口就能用了。相反，其他IPC都不能跨机器。

其次，我兄弟天天给我吹他学的服务器到后面可以跨平台，Windows和Linux上交互，我问他他说还没学到，那现在呢？就让我先剧透吧哈哈哈哈。

在编程上，TCP sockets和pipe都是操作文件描述符，用来收发字节流，都可以read/write/fcntl/select/poll等，不同的是，TCP是全双工的，pipe是半双工的，不方便。

就拿最快的IPC，shm共享内存来说，就那么好用？对于技术不过硬的朋友来说，那可真的是坑坑洼洼，反正我是鼻青脸肿了。或许有人会说，具体问题具体分析，单机就用shm,分布式就用TCP，我想问问，有意思吗？有意思吗？就那么喜欢为一个功能写两份代码啊。在比对一下shm与TCP，TCP是字节流协议，只能顺序读取，有写缓冲；shm是消息协议，一个进程把内容写入虚拟地址，由另一个进程来读走，基本上可以说是阻塞。

其实我是很喜欢shm通信的，甚至都封装了动态库，在我的“动态库”专栏下就能找到，但是吧，叛变就是这么的快哈哈哈。

再者，IPC通信崩溃会怎样？段错误；TCP呢?网络掉线，哪个好找？一目了然。 TCP一断掉，哪里断了哪里重连就好，IPC呢？那就得全部重头来过。

使用TCP长连接通信

使用TCP长连接通信的好处有两点：

容易定位分布式系统中的服务之间的依赖关系。只要在机器上运行netstat -tpna | grep : port 就能立刻列出用到某服务的客户端地址，然后在客户端上用netstat或lsof命令找出是哪个进程发起的连接。这样在迁移服务的时候可以有效的防止出现outage。 TCP短连接和UDP连接则不具备这一特性。
通过收发队列的长度也比较容易定位网络中或程序故障。在正常运行时，netstat打印的Recv-Q和Send-Q都接近于0，或者在0附近波动。如果Recv-Q保持不变或持续增加，一般是服务进程的处理速度变慢，可能是死锁或阻塞了。如果Send-Q保持不变或持续增长，那可能是对方服务器太忙，没空理你，也有可能是网络中某个路由器或者交换机挂了，甚至对方掉线了。

下面是个示例：