mq

PHP高级编程之消息队列 http://netkiller.github.io/journal/php.mq.html Mr . Neo Chen (陈景峰) , netkiller, BG7NYT 中国 广东省 深圳市 龙华新区民治街道溪山美地 518131 +86 13113668890 +86 755 29812080 < netkiller@msn.com > 版权声明 转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。 文档出处: http://netkiller.github.io http://netkiller.sourceforge.net 微信扫描二维码进入 Netkiller 微信订阅号 QQ群：128659835 请注明“读者” 2015-10-19 摘要 我的系列文档 Netkiller Architect 手札 Netkiller Developer 手札 Netkiller PHP 手札 Netkiller Python 手札 Netkiller Testing 手札 Netkiller Cryptography 手札 Netkiller Linux 手札 Netkiller Debian 手札 Netkiller CentOS 手札 Netkiller FreeBSD 手札 Netkiller Shell 手札 Netkiller

知识先知 其实引入这个解决方案,纯属是因为在项目中有这样的应用场景; 何为解决方案 ,其实通俗讲就是针对于某些应用场景,选取适合的解决办法,这里指的是较好的,或许解决方案会有许多,包括MQ消息队列要解决的应用场景。 前因后果 场景一、目前常见的分布式服务项目，都是通过服务于服务之间进行通信完成各自的业务逻辑，因此相互之间耦合性比较较大； （1）只要中间服务出了故障后，上游和下游都会受到波及，同时相互之间的调用关系为被动； （2）后期进行扩增和删减的话，都会波及依赖的服务； 解决方式：引用MQ后，上游服务只负责将下游想要的东西发送给它，至于下游如何处理，这就不是上游需要考虑的问题了；相互之间的调用关系为主动。 场景二、一些大数据量的频繁同步处理，一个系统如果不光在本项目读写数据，而且还要调用其他项目操作库，这时候，他们之间的处理如果是同步的话，损耗的时间就是两者之和了。 解决方式：引入MQ后，上游系统连续发送消息到MQ队列中,直接返回；当然也可以利用多线程的方式解决，但是会造成单体服务内存损耗。 场景三、比如某个业务处理过程一直都处于稳定状态，但是某一时间点后，用户请求量突增，针对于这种场景，提升服务器的硬件显然不是最好的方式。 解决方式：引入MQ后，利用消息队列持久化存储的机制，可以避过短时间业务量突增的场景，稍后等到请求平稳后，慢慢处理业务量。 合理分析 难道说

目前业界有很多MQ产品，我们作如下对比： RabbitMQ 是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。 Redis 是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 入队 出队 128B 512B 1K 10K 128B 512B 1K 10K Redis 16088 15961 17094 25 15955 20449 18098 9355 RabbitMQ

参考资料 <<精通Linux C编程>> http://man7.org/linux/man-pages/man2/open.2.html https://www.cnblogs.com/52php/p/5840229.html 在 Android中的Handler的Native层研究 文章中研究一下一把Linux中的匿名管道的通信机制，今天这里Linux中的进程间通信补齐。 在Linux中，实现进程通信的方法包括管道(匿名管道和具名管道)，消息队列，信号量，共享内存，套接口等。消息队列，信号量，共享内存统称为系统的(POSIX和System V)IPC，用于本地间的进程通信，套接口(socket)则运用于远程进程通信。 各个通信机制定义如下： 匿名管道(Pipe)和具名管道(named pipe)：匿名管道用于具有亲缘关系进程间的通信，具名管道克服了管道没有名字的限制，因此除了具有匿名管道的功能外，还允许在无亲缘关系的进程中进行通信。 消息队列(Message)：消息队列为消息的链接表，包括POSIX消息队列和System V消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读取队列中的消息。 共享内存：是的多个进程可以访问同一块内存空间，是最快的可以IPC形式。是针对其他的通信机制运行效率较低而设计出来的。往往与其他通信机制，如信号量结合使用

消息队列可以当做一个消息链表，不同于FIFO和管道，某个进程往一个消息队列写入消息之前，不需要另外进程在该队列上等待消息的到达。 对posix消息队列的读总是返回最高优先级的最早消息。 常用函数： 创建或者打开一个消息队列： #include <fcntl.h> /* For O_* constants */ #include <sys/stat.h> /* For mode constants */ #include <mqueue.h> mqd_t mq_open(const char *name, int oflag); mqd_t mq_open(const char *name, int oflag, mode_t mode, struct mq_attr *attr); 关闭消息队列： #include <mqueue.h> int mq_close(mqd_t mqdes); 删除消息队列: posix消息队列具备随内核的持续性，就是说即使当前没有进程打开某个消息队列，该队列上的消息也将一直存在。 #include <mqueue.h> int mq_unlink(const char *name); 要真正的删除一个消息队列得这样：调用mq_unlink并让它的引用计数（close一次减少1）达到0。 获取消息队列属性： #include <mqueue.h>

概述 WebSphere MQ作为IBM软件家族的消息传输中间件产品，以其出色的特性和功能在业界享有盛誉。WebSphere MQ独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性，以及强大的消息通讯能力，使得它在银行、电信，还是在交通运输、政府机关等各行各业，赢得了很高的市场份额。在中国，WebSphere MQ同样拥有广泛的用户基础和许许多多的成功案例。它不仅具有跨平台、跨网络的特性，而且以其特有的先进机制保证对消息的"Once and Once only"的传输，做到不丢失、不复传。在WebSphere MQ给客户带来的众多价值中，有一点十分重要，就是它的通讯感知和恢复机制，尤其适用于我国目前的现状，在我国很多地方存在网络线路质量差，网络状态不稳定的现状。因为WebSphere MQ在支持同步通讯的同时，提供了基于消息队列存储-转发机制的异步通讯模式，应用程序只需将消息交给WebSphere MQ，就由WebSphere MQ负责将消息安全、可靠地发送出去，不再需要应用和人工的干预，当网络出现故障的情况下，或对方主机发生故障时，WebSphere MQ能够作到不需要人工干预，自动探测网络状况的好坏，并且在网络恢复正常之后能够继续正常工作，也即断点续传。 在WebSphere MQ的系统配置和维护中，通道(Channel

什么是MQ？ MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。 RabbitMQ是MQ的一种。下面详细介绍一下RabbitMQ的基本概念。 1、队列、生产者、消费者 队列是RabbitMQ的内部对象，用于存储消息。生产者（下图中的P）生产消息并投递到队列中，消费者（下图中的C）可以从队列中获取消息并消费。 多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。 2、Exchange、Binding 刚才我们看到生产者将消息投递到队列中，实际上这在RabbitMQ中这种事情永远都不会发生。实际的情况是，生产者将消息发送到Exchange（交换器，下图中的X），再通过Binding将Exchange与Queue关联起来。 3、Exchange Type、Bingding key、routing key 在绑定（Binding）Exchange与Queue的同时，一般会指定一个binding key。在绑定多个Queue到同一个Exchange的时候，这些Binding允许使用相同的binding key。 生产者在将消息发送给Exchange的时候，一般会指定一个routing