这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
概述
消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。
消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
组成
Broker
消息服务器，作为server提供消息核心服务
Producer
消息生产者，业务的发起方，负责生产消息传输给broker，
Consumer
消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
Topic
主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的 广播
Queue
队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
Message
消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输
应用场景
异步处理
消息队列的主要特点是异步处理，主要目的是减少请求响应时间，实现非核心流程异步化，提高系统响应性能。
应用解耦
使用了消息队列后，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦。
每个成员不必受其他成员影响，可以更独立自主，只通过消息队列MQ来联系，典型的上下游解耦：
流量削锋
流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。
这种场景中系统的峰值流量往往集中于一小段时间内，所以为了防止系统在短时间内的峰值流量冲垮，往往采用消息队列来削弱峰值流量，相当于消息队列做了一次缓冲。
日志处理
日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。
设计
整体架构
涉及三类角色：
1）Producer 消息生产者：负责产生和发送消息到 Broker；
2）Broker 消息处理中心：负责消息存储、确认、重试等，一般其中会包含多个 queue；
3）Consumer 消息消费者：负责从 Broker 中获取消息，并进行相应处理；
详细设计
producer发送给broker,broker发送给consumer,consumer回复消费确认，broker删除/备份消息等。
1）RPC 通信
第一个步骤:Producer生产消息向Broker发送会涉及到通信的问题，同样Consumer 消费消息也会涉及到通信的问题。
Producer,Broker,Consumer最后就通过RPC将数据流串起来了，所以需要解决通信的问题。
基于Netty 来做底层通信，用 Zookeeper、Euraka 等来做注册中心，然后自定义一套新的通信协议。
也可以直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 实现即可，这样不需要考虑服务注册与发现、负载均衡、通信协议、序列化方式等一系列问题了。
2）Broker存储
第二个步骤，消息到达服务端后需要存储到Broker。
大家关注的流量削峰、最终一致性等需求都是需要Broker先存储下来，然后选择时机投递，这才达到流量削峰、泄洪的目的，所以Broker一个非常重要的功能就是存储。
存储可以做成很多方式，比如存储在内存里，存储在分布式KV里，存储在磁盘里，存储在数据库里等等，存储的选型需要综合考虑性能/高可用和开发维护成本等诸多因素。
目前主流的方案：追加写日志文件（数据部分） + 索引文件的方式，索引设计上可以考虑稠密索引或者稀疏索引，查找消息可以利用跳转表、二份查找等，还可以通过操作系统的页缓存、零拷贝等技术来提升磁盘文件的读写性能。
3）消费模型
第三个步骤，消息到达Broker后，最终还是需要Consumer去消费消息，这里就会涉及到到消费模型。
这里的消费模型，目前主要就两种：单播和广播。所谓单播，就是点到点；而广播，是一点对多点。
详细的单播和广播消费模型，下面我会图文详解。
4）高级特性
第四个步骤，如果Consumer端把消息消费了，除了需要消息确认，还会涉及到比如：重复消息、顺序消息、消息延迟、事务消息等需要考虑的高级特性。
模型
消息队列MQ主要包含两种模型：点对点与发布订阅两种模型。
点对点模型
点对点模用于 消息生产者 和 消息消费者 之间 点到点 的通信，包含三个角色：
- 消息队列（Queue）
- 发送者(Sender)
- 接收者(Receiver)
每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在 内存 中也可以 持久化，直到他们被消费或超时。
特点
- 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
- 发送者和接收者之间在时间上没有依赖性
- 接收者在成功接收消息之后需向队列应答成功
发布订阅消息模型Topic
发布订阅模型包含三个角色：
- 主题（Topic）
- 发布者（Publisher）
- 订阅者（Subscriber）
多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
特点
- 每个消息可以有多个消费者：和点对点方式不同，发布消息可以被所有订阅者消费
- 发布者和订阅者之间有时间上的依赖性。
- 针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
- 为了消费消息，订阅者必须保持运行的状态。
产品选型
RocketMQ
阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：
- 能够保证严格的消息顺序
- 提供针对消息的过滤功能
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
官方提供了一些不同于kafka的对比差异：
https://rocketmq.apache.org/docs/motivation/
RabbitMQ
使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。
ActiveMQ
Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
Redis
使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
Kafka
Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：
- 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
- 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
- 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
- 完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
- 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
ZeroMQ
号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。
特性：
- 无锁的队列模型：对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。
- 批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。
- 多核下的线程绑定，无须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。
Pulsar
Apache Pulsar是Apache软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性，被看作是云原生时代实时消息流传输、存储和计算最佳解决方案
主要消息中间件的比较
综合考虑选择RabbitMq
标签：订阅,存储,--,Broker,队列,MQ,消息,青训营,ZeroMQ From： https://www.cnblogs.com/peace0218/p/17065695.html