初探消息中间件

消息中间件组成

1. broker

消息服务器，作为server提供消息核心服务

2. producer

消息生产者，业务的发起方，负责生产消息传给broker

3. consumer

消息消费者，业务处理方，负责从broker获取消息并进行业务逻辑处理

4. topic

主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，有mq服务器分发到不同订阅者，实现消息的广播

5. queue

队列，ptp模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接受

6. message

消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

模式分类

点对点(ptp)

使用queue作为通信载体。producer生产消息后发送到queue中，consumer从queue中取出消息并消费。当消息被消费后，queue不在存储，所以consumer不能消费到已经被消费的消息。

queue允许多个consumer的存在，但是每个消息只能对应一个consumer，所以是点对点。

发布/订阅(Pub/Sub,广播)

使用topic作为通信载体。producer将消息发布到topic中，多个订阅了此topic的consumer都可以接收并消费该消息。

queue实现了负载均衡，消息被发送到消息队列中时，可以有多个consumer消费，但由于一个消息只能被一个消费者接受，所以， 当没有可接受的消费者时，消息将会被queue保存，知道有可用的consumer。

topic中发布的任务，所有订阅这个topic的服务都能得到此消息的拷贝。

优势

1. 系统解耦

交互系统之间没有直接调用关系，只有消息传输，所有系统侵入不强，耦合性低。

2. 提高系统响应时间

可以将连续的一系列逻辑，分开处理，将响应要求不高的业务放在queue中，供消费者处理。

3. 为大数据处理架构提供服务

MQ与实时处理架构整合，为大数据提供性能支持。

4. Java消息服务——JMS(Java Message Service, JMS)

是一个java平台关于面向消息中间件(MOM)的API， 用于两个应用程序之间，或分布式系统中发送消息，进行异步通信。MQ的消息模式，最初是由JMS定义的。

应用场景

1. 异步通信

对于不需要立即处理的业务，可以利用queue来存放，等需要时再处理。

2. 解耦

降低工程间的强依赖程度，对于异构系统，在MQ处理过程中插入一个隐含的、基于数据的接口层，用于发生变化时的同步和修改。

3. 冗余

处理数据过程失败，若数据没有被持久化，将会造成数据丢失。利用MQ将数据持久化直至完成数据的处理。

4. 扩展性

MQ解耦了处理过程，所以可以轻易增大消息入队和处理的频率，只需要另外增加处理过程，便于分布式扩容。

5.过载保护(流量削峰)

访问量剧增情况下，可以利用MQ来阻挡突增的访问量，防止系统因超负荷而崩溃。

6. 可恢复性

组件一部分失效时，仍然不会影响整个系统。需要处理的消息放到MQ中，即使处理消息的进程失效，queue中的消息仍然可以在复原后被处理。

7.顺序保证

可以利用queue来保证数据处理的顺序。

8. 缓冲

有时系统需要不同时间来处理数据，MQ通过缓冲层来调节数据流经系统的速度，从而调节系统响应时间。

9. 数据流处理

收集大批量数据，例如日志，用户行为数据等。

10. 消息通讯

利用点对点队列，实现即时通讯功能

常用协议

1. AMQP(Advanced Message Queuing Protocol)

用于应用层的提供统一消息服务的标准高级消息队列协议，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，不受产品，开发语言等条件限制。

优点：可靠，通用

2. MQTT(Message Queuing Telemerty Transport， 消息队列遥测传输)

即时通讯协议，支持所有平台，可以将联网物品和外部连接，被用来当作传感器和制动器。

优点：格式简洁，占用带宽小，移动端通信，PUSH，嵌入式系统

3. STOMP(Streaming Text Orientated Message Protocol， 流文本定向消息协议)

是为MOM设计的简单文本协议。其提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理(Broker)进行交互。

优点： 命令模式(非topic\queue模式)

4. XMPP(Extensible Messaging and Presence Protocol, 可扩展消息处理现场协议)

基于XML的协议，多用于即时消息和在线现场探测。核心为XML流传输。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大。

5. 其他基于TCP/IP自定义的协议

有些特殊框架，基于TCP/IP自行封装了一套协议，例如网络socket接口进行传输。

常见MQ介绍

1. RocketMQ

阿里系下开源的分布式、队列模型的MQ，3.0版本后改名为RocketMQ，参照kafka设计思想，使用Java实现。同时整合多个阿里系MQ产品，只维护核心功能，配合阿里其他开源产品实现不同场景MQ的架构。

特点：

• 严格保证消息顺序
• 消息过滤
• 消息拉取模式丰富
• 订阅者水平扩展能力较高效
• 实时的消息订阅机制
• 亿级消息堆积能力

2. RabbitMQ

使用Erlang编写的开源消息队列，本身支持多种协议，重量级，更适合企业级的开发。同时实现broker架构，核心思想是生产者不会将消息直接发给队列，而是现在中心队列排队。对路由、负载均衡、数据持久化独有很好的支持。多用于ESB整合。

3. ActiveMQ

Apache下的子项目，可插拔的传输协议支持，使用Java实现，完全支持JMS1.1和J2EE1.4规范。支持多种语言客户端。

4. Redis

C语言开发的Key-Value型的NOSQL数据库，本身支持MQ，可以当作一个轻量级的queue来使用。

PS：Redis和RabbitMQ对比：

入队：data量<10K, Redis性能高于RabbitMQ；data量 >10K，Redis非常慢。出队：无论多少数据量，Redis性能高于RabbitMQ

5. Kafka

Apache下子项目，使用scala实现的高性能分布式Publish/Subscribe消息队列系统。

• 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的开销下进行持久化
• 高吞吐：在一台普通的服务器上可以达到10W/s的吞吐速率
• 高堆积：支持topic下消费者较长时间离线，消息堆积两大
• 完全分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡
• 支持Hadoop数据并行加载：支持像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制。

6. ZeroMQ

专用于高吞吐量/低延迟的场景开发，常用于金融行业应用，偏重于实时数据通信场景。ZeroMQ有一个非中间件模式，此模式下应用本身会成为利用ZeroMQ API完成逻辑服务的角色，不需要安装和运行消息服务器或中间件。但ZeroMQ仅提供非持久性的队列，最造成数据丢失。

ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。

• 无锁的队列模型：跨线程间的交互，数据交换使用pipe，采用CAS算法；在pipe两端注册有异步事件，在读写消息到pipe时，会自动触发读写事件。
• 批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接受和发送消息
• 多核下的线性绑定，无需CPU切换：区别于传统的多线程并发模式，信号量或临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的cpu切换开销。

主要中间件比较

参考博客：
https://blog.csdn.net/wqc19920906/article/details/82193316

未完待续~撒花