什么是mq
Message Queue(MQ）。消息对列中间件。很多人说：MQ是通过将消息的发送和接收分离来实现应用程序的一步和解耦，这个给人的直觉是--MQ是异步的，用来解耦的，但是这个只是MQ的效果而不是目的。MQ真正的目的是wield通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的，钢架简单的通讯协议，一个分布式系统中2个木块之间要么是HTTp,要么是自己开发的TCp，但是这2个协议其实都是原始的狭义，Http协议很难实现俩端通讯--模块A可以调用B，B也可以主动调用A，如果要做到这个2端都要背上webserver，而且还不支持长连接（HTTp 2.0 的库根本找不到），tcp就更加原始了，粘包，心跳，私有的协议，想一想就头皮发麻。MQ带给我们的协议之上构建一个简单的协议---生产者/消费者模型。mq的协议不是具体的通讯协议，而是更高层次通讯模型。它定义了2个对象---发送数据的叫生产者；接收数据的叫消费者。提供一个SDK让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议。
有Broker的MQ
这个流派通常有一台服务器作为Broker，所有的消息都通过他中转。生产者把消息发送给他就结束自己的任务了。Broker把消息主动推送给消费者（或者消费者主动轮询）
重Topic
kafka,JMS(ActiveMq)就属于这个流派，生产者会发送key和数据到Broker，有broker比较key之后决定给那个消费者。这种消费模式是我们最常见的模式，使我们对MQ最多的印象，在这种模式下一个topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个topic，topic某种意义上就是queque，生产者发送key相当于说hi, 把数据放到key的队列中。
如上图所示，Broker定义了三个对列，key1,key2,key3, 生产者发送数据的时候发送key1,和data，Broker 在推送数据的时候则推送data（也可能把key也带上）
虽然架构一样但是kafka 的性能要比jms的性能不知道要高多少倍，所以基本这种类型的MQ只有kafka 一种备选方案。如果你需要一种暴力的数据流（在乎性能而非灵活性）那么 kafka 是最好的选择。
轻Topic
这种代表是RabbitMQ()或者说AMQP,生产者发送key和数据，消费者定义订阅的对列，Broker 收到数据之后会通过一定的逻辑计算出key对应的对列，然后把数据交给对列。
这种模式下解耦了key 和 queue， 在这种架构中 queue 是非常轻量级的（在RabbitMq中它的上限取决于你的内存）。消费者关心的只是自己的queue; 生产者不必关心数据最终给谁只要指定key 就行了，，中间那层映射在AMQP中叫exchange(交换机)
AMQp z中有四种exchange
Direct exchange: key 就等于queue
Fanout exchange: 无视 key,给所有的queue 都来一份
Topic exchange： key 可以用宽字符 模糊匹配queue
Headers exchange: 无视key，通过查看消息的头部元素来决定发给那个queue（AMQP头部元数据非常丰富而且可以自定义）
这种结构的架构给通讯带来了很大的灵活性，我们能想到的通讯方式都可以用这四种exchange 表达出来。如果你需要一个企业数据总线（在乎灵活性）。那么RabbitMQ 绝对值得一用。
无Broker的 mq
无 Broker 的MQ 的代表是ZeroMQ，该作者非常的睿智，他非常敏锐的意识到--MQ是更高级的Socket，他是解决通讯问题的。所以ZeroMQ被设计成了-个库而不是一个中间件，这种实现也可以达到---- 没有Broker的目的。
节点之间通讯的消息都是发送到彼此的队列中，每个节点都是即是生产者也是消费者。ZeroMq 做的事情就是封装出一套类似于Socket的APi可以完成发送数据，读取数据
ZerMQ 其实就是一个跨语言的，重量级的Actor 模型邮箱库。你可以把自己的程序想像成一个Actor，ZeroMQ 就是提供邮箱功能的库；ZeroMq可以实现同一台机器的RPC通讯也可以实现不同机器的TCp，UDP 通讯。如果你需要有个强大的灵活的野蛮的通讯能力，ZeroMQ
f附：Queue 和Topic 的区别：
Queue： 一个发布者发布消息，下面的接受者安对列顺序接收，比如发布了10个消息，2个接受者A,B那就是A,B 总共会收到10条消息，不重复。
Topic 一个发布者发布消息有2个接受者a,b来订阅，那么发布了10条消息，a,b 收到10条消息
