IPC、消息队列与zeroMQ

1、IPC的目的

数据传输：一个进程需要将它的数据发送给另一个进程，发送的数据量在一个字节到几M字节之间

共享数据：多个进程想要操作共享数据，一个进程对共享数据的修改，别的进程应该立刻看到。

通知事件：一个进程需要向另一个或一组进程发送消息，通知它（它们）发生了某种事件（如进程终止时要通知父进程）。

资源共享：多个进程之间共享同样的资源。为了作到这一点，需要内核提供锁和同步机制。

进程控制：有些进程希望完全控制另一个进程的执行（如Debug进程），此时控制进程希望能够拦截另一个进程的所有陷入和异常，并能够及时知道它的状态改变。

2、Linux系统的IPC方式

文件（磁盘，效率低）、管道（有名管道 磁盘，效率低，无名管道 内存中）、信号（一般只做同步用）、消息队列（在内核中）、共享内存（最快，需考虑同步）、套接字

1.管道：速度慢，容量有限，只有父子进程能通讯

2.FIFO：任何进程间都能通讯，但速度慢

3.消息队列：容量受到系统限制，且要注意第一次读的时候，要考虑上一次没有读完数据的问题

消息队列使用：https://blog.csdn.net/yang_yulei/article/details/19772649

4.信号量：不能传递复杂消息，只能用来同步

5.共享内存区：能够很容易控制容量，速度快，但要保持同步，比如一个进程在写的时候，另一个进程要注意读写的问题，相当于线程中的线程安全，当然，共享内存区同样可以用作线程间通讯，不过没这个必要，线程间本来就已经共享了同一进程内的一块内存。

共享内存使用：http://blog.chinaunix.net/uid-26833883-id-3230564.html

3、UNIX Domain Socket

虽然网络socket也可用于同一台主机的进程间通讯（通过loopback地址127.0.0.1），但是UNIX Domain Socket用于IPC更有效率：不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用层数据从一个进程拷贝到另一个进程。这是因为，IPC机制本质上是可靠的通讯，而网络协议是为不可靠的通讯设计的。UNIX Domain Socket也提供面向流和面向数据包两种API接口，类似于TCP和UDP，但是面向消息的UNIX Domain Socket也是可靠的，消息既不会丢失也不会顺序错乱。

UNIX domain socket 与网络 socket 编程最明显的不同在于地址格式不同，用结构体 sockaddr_un 表示，网络编程的 socket 地址是 IP 地址加端口号，而 UNIX domain socket 的地址是一个 socket 类型的文件在文件系统中的路径，这个 socket 文件由 bind() 调用创建，如果调用 bind() 时该文件已存在，则 bind() 错误返回。因此，一般在调用 bind() 前会检查 socket 文件是否存在，如果存在就删除掉。

4、消息队列（非系统自带的消息队列）

       使用第三方消息队列而不使用系统消息队列是因为第三方消息队列封装了一些很有用的特性，使用方便，比如选择使用模式，设置各种参数如水位、超时时间等等，不用自己管理内部过程，开发效率高并且可靠。目前我使用得最多的是0mq。0mq中的ipc模式就第3章中的模式。

 

参考网址：https://www.cnblogs.com/xuyatao/p/6864109.html

消息队列的使用原因：主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。

在所有企业应用系统中，无一例外地都采用（或在某些子系统与模块中部分采用）了基于消息的分布式架构。但是不同之处在于，让我们做出架构决策的证据却迥然而异，这也直接影响我们所要应用的消息模式。

 

消息模式主要有：点对点、发布/订阅、PUSH/PULL。

 

参考网址：https://www.cnblogs.com/tianqing/p/7110468.html

https://blog.csdn.net/woshirongshaolin/article/details/70503988

消息队列应用场景：

异步处理：例如短信通知、终端状态推送、App推送、用户注册等

数据同步：业务数据推送同步

重试补偿：记账失败重试

系统解耦：通讯上下行、终端异常监控、分布式事件中心

流量消峰：秒杀场景下的下单处理

发布订阅：HSF的服务状态变化通知、分布式事件中心

高并发缓冲：日志服务、监控上报

 

参考网址：https://blog.csdn.net/jiangshouzhuang/article/details/79452047

现在比较常见的MQ产品主要是ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。

ZeroMQ号称是“史上最快的消息队列”，基于c语言开发的，可以在任何平台通过任何代码连接，通过inproc、IPC、TCP、TIPC、多播传送消息，支持发布-订阅、推-拉、共享队列等模式，高速异步I/O引擎。ZeroMQ不支持消息持久化。

 

RabbitMQ是基于Erlang语言编写的开源消息队列，通过Erlang的Actor模型实现了数据的稳定可靠传输。本身是实现AMQP的消息队列，不仅是协议支持的多，还因为它实现了代理(Broker)架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，适宜于很多场景如路由、负载均衡或消息持久化等，用消息队列只需几行代码即可搞定。但是，这使得它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大，如需配置RabbitMQ则需要在目标机器上安装Erlang环境。

 

ActiveMQ介于ZeroMQ和RabbitMQ之间。类似于ZeroMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景，而且只需付出低消耗。被誉为消息中间件的“瑞士军刀”

 

Kafka是一个高性能跨语言分布式Publish/Subscribe消息队列系统，以Pull的形式消费消息。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡。因为设计之初是作为日志流平台和运营消息管道平台，所以实现了消息顺序和海量堆积。Kafka自身服务与消息的生产和消费都依赖与Zookeeper，使用Scala语言开发。

 

RocketMQ是阿里开源的消息中间件，目前在Apache孵化，使用纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。

 

ZeroMQ小而美，RabbitMQ大而稳，Kakfa和RocketMQ快而强劲。

5、zeromq

史上最快的消息队列，基于c语言开发的（C和python都有对应的库），实时流处理sorm的task之间的通信就是用的zeroMQ。

ZeroMQ与其他MQ类似，也实现了3中最基本的工作模式：发布-订阅，请求-应答，管道。

push/pull模式：http://iyuan.iteye.com/blog/974040

 

zmq api函数说明：

http://www.cnblogs.com/fengbohello/p/4230135.html

zmq使用实例：

http://www.cnblogs.com/fengbohello/p/4046686.html

zmq学习博客：

https://www.cnblogs.com/fengbohello/tag/zeromq/

https://blog.codingnow.com/2011/02/zeromq_message_patterns.html