消息队列浅谈（各种消息队列和协议）

不同技术的选择，其实无非两点。一个是技术的初衷，一个是技术本身的成熟度。技术能不能火，一部分依靠是否前瞻，一部分依靠实现的稳定高效率和优雅。（当然还有一部分要靠无休止的撕逼。。。）程序员的江湖，有时候也是令人感叹。

基本概念

消费者 与 消息存储方Broker一般有两种通信机制：推（PUSH）、拉(PULL)
推模式：消息发送者将消息发送到Broker，然后Broker主动推送给订阅了该消息的消费者。
拉模式：消息发送者将消息发送到Broker上，然后由消息消费者自发的向Broker拉取消息。

推模式

优点当然是快。一般是采取客户端和服务器端建立长连接来实现的。

• 原来的一个缺点是客户端机器多，所以server端的长连接的数量太多。但是netty等NIO框架的出现让这些都不是事。
• 另一个问题是抗堆积性不好。server需要对堆积的大量数据发起大量随机的读写。无论是关系型数据库，还是采用LSM架构的HBASE（主要是随机读的问题），都难以胜任。

拉模式

缺点当然是慢。

• 优点是采用顺序读写，所以文件就可以了。

JMS

ActiveMQ

支持 JMS1.1 和J2EE1.4中关于消息队列的一种实现。JMS协议推出的初衷就是要让所有程序员在操作消息队列时遵循相同的API，这样，就可以方便的更改JMS的具体实现。

刚刚出来的时候只有BIO模式，所以最大连接数是有问题的。后来支持NIO，可以通过调整线程池来提高连接数。

它的HA主流的是master-slave。客户端只和master沟通，master死了之后才会切换到slave。也可以多个broker组成集群，当其中一个broker的消费者出问题导致消息堆积无法消费掉时，通过ActiveMQ支持的Network of Broker方案可将该broker堆积的消息转发到其他有消费者的broker。

一个Queue可以设置多个消费者。

AMQP协议

这个协议是JP摩根在2006年拉着一堆非互联网企业设计并制定。代表企业有思科，微软，红帽,iMatix…。噱头是并不需要开发者遵循相同的API，而是要求中间件开发者保持其中间件中间的互通。注意还有一个MQTT，那个是一个和HTTP一样的应用层协议，用于物联网发布和订阅消息队列。这俩不是一回事。

RabbitMQ

2007年开始开发。
RabbitMQ同样是AMQP规范的一种实现。但是并不仅仅是这个，支持很多的协议AMQP,XMPP, SMTP, STOMP。也正因如此,它非常重量级,更适合于企业级的开发。同时实现了Broker构架,这意味着消息在发送给客户端时先在中心队列排队。对路由,负载均衡或者数据持久化都有很好的支持。

RabbitMQ采用的是消息推送模型。利用了TCP的全双工通信性能。客户端和服务器端保持了长连接。

rabbitMQ提供了基于文件系统的持久化方案，回溯消费能力，定时消费能力，分布式事务。

RocketMQ

RocketMQ是AMQP规范的一种实现（2012～2016由阿里研发，后来捐给apache）。
提供的功能和rabbitMQ类似。

RocketMQ推拉机制实现：
严格意义上来讲，RocketMQ并没有实现PUSH模式，而是对拉模式进行一层包装，在消费端开启一个线程PullMessageService循环向Broker拉取消息，一次拉取任务结束后马上又发起另一次拉取操作。

https://blog.csdn.net/define_us/article/details/83309749

ZeroMQ

可能是最另类的消息中间件。
我们讨论AMQP时，提到了一家企业叫做iMatix。这家企业为了2010年开发自己的zeroMQ离开了AMQP的workgroup。自以为自己的ZeroMQ是更快速的实现。所以zeroMQ并不支持AMQP。

Kafka

提到kafka，大多数人会吹嘘其吞吐量，无非是以下的几个原因。

• 顺序读写
• 零拷贝 正是因为分了partion，才方便进行零拷贝。
• 文件分段：操作小文件肯定比大文件要方便。
• 批量发送
• 数据压缩

下图是网上找的大牛的

• 这个图说，rabbitMQ的延迟只有微秒级别是完全夸张了。但是他是采用推送模型的，延迟较低是合理。

其他

当然还有一些消息队列。

notify

淘宝的。2007年诞生。用作核心交易链路的解耦。这是一个长连接的推模式的。

METAQ

淘宝的。改自kafka。采长轮训的拉模式。说白了就是节约成本，没必要做推模式的就不做。

MSGBROKER

ANTQ