消息中间件（⼀）：MQ（消息队列）详解及四⼤MQ⽐较 ⼀、消息中间件相关知识
1、概述
消息队列已经逐渐成为企业IT系统内部通信的核⼼⼿段。它具有低耦合、可靠投递、⼴播、流量控制、最终⼀致性等⼀系列功能，成为异步RPC的主要⼿段之⼀。当今市⾯上有很多主流的消息中间件，如⽼牌的ActiveMQ、RabbitMQ，炙⼿可热的Kafka，阿⾥巴巴⾃主开发RocketMQ等。 2、消息中间件的组成
2.1 Broker
消息服务器，作为server提供消息核⼼服务
2.2 Producer
消息⽣产者，业务的发起⽅，负责⽣产消息传输给broker，
2.3 Consumer
消息消费者，业务的处理⽅，负责从broker获取消息并进⾏业务逻辑处理
2.4 Topic
主题，发布订阅模式下的消息统⼀汇集地，不同⽣产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的 ⼴播
2.5 Queue
立式真空炉队列，PTP模式下，特定⽣产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
2.6 Message
消息体，根据不同通信协议定义的固定格式进⾏编码的数据包，来封装业务数据，实现消息的传输
3 消息中间件模式分类
3.1 点对点
PTP点对点：使⽤queue作为通信载体
说明：
消息⽣产者⽣产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue⽀持存在多个消费者，但是对⼀个消息⽽⾔，只会有⼀个消费者可以消费。
3.2 发布/订阅
Pub/Sub发布订阅（⼴播）：使⽤topic作为通信载体
说明：
消息⽣产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点⽅式不同，发布到topic的消息会被所有订阅者消费。
queue实现了负载均衡，将producer⽣产的消息发送到消息队列中，由多个消费者消费。但⼀个消息只能被⼀个消费者接受，当没有消费者可⽤时，这个消息会被保存直到有⼀个可⽤的消费者。
topic实现了发布和订阅，当你发布⼀个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到⼀个消息的拷贝。
监控摄像机主板4 消息中间件的优势
4.1 系统解耦
交互系统之间没有直接的调⽤关系，只是通过消息传输，故系统侵⼊性不强，耦合度低。
4.2 提⾼系统响应时间
例如原来的⼀套逻辑，完成⽀付可能涉及先修改订单状态、计算会员积分、通知物流配送⼏个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要⽴刻响应）的业务放到该调⽤⽅法中，响应要求不⾼的使⽤消息队列，放到MQ队列中，供消费者处理。
4.3 为⼤数据处理架构提供服务
通过消息作为整合，⼤数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能⽀持。
4.4 Java消息服务——JMS
Java消息服务（Java Message Service，JMS）应⽤程序接⼝是⼀个Java平台中关于⾯向消息中间件（MOM）的API，⽤于在两个应⽤程序之间，或分布式系统中发送消息，进⾏异步通信。
JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，
topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。
5 消息中间件应⽤场景
5.1 异步通信
有些业务不想也不需要⽴即处理消息。消息队列提供了异步处理机制，允许⽤户把⼀个消息放⼊队列，但并不⽴即处理它。想向队列中放⼊多少消息就放多少，然后在需要的时候再去处理它们。
5.2 解耦
降低⼯程间的强依赖程度，针对异构系统进⾏适配。在项⽬启动之初来预测将来项⽬会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插⼊了⼀个隐含的、基于数据的接⼝层，两边的处理过程都要实现这⼀接⼝，当应⽤发⽣变化时，可以独⽴的扩展或修改两边的处理过程，只要确保它们遵守同样的接⼝约束。
5.3 冗余
有些情况下，处理数据的过程会失败。除⾮数据被持久化，否则将造成丢失。消息队列把数据进⾏持
久化直到它们已经被完全处理，通过这⼀⽅式规避了数据丢失风险。许多消息队列所采⽤的”插⼊-获取-删除”范式中，在把⼀个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从⽽确保你的数据被安全的保存直到你使⽤完毕。
5.4 扩展性
因为消息队列解耦了你的处理过程，所以增⼤消息⼊队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
5.5 过载保护
数字电视手机
在访问量剧增的情况下，应⽤仍然需要继续发挥作⽤，但是这样的突发流量⽆法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投⼊资源随时待命⽆疑是巨⼤的浪费。使⽤消息队列能够使关键组件顶住突发的访问压⼒，⽽不会因为突发的超负荷的请求⽽完全崩溃。
5.6 可恢复性
系统的⼀部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使⼀个处理消息的进程挂掉，加⼊队列中的消息仍然可以在系统恢复后被处理。
5.7 顺序保证
在⼤多使⽤场景下，数据处理的顺序都很重要。⼤部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
5.8 缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过⼀个缓冲层来帮助任务最⾼效率的执⾏，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
5.9 数据流处理
分布式系统产⽣的海量数据流，如：业务⽇志、监控数据、⽤户⾏为等，针对这些数据流进⾏实时或批量采集汇总，然后进⾏⼤数据分析是当前互联⽹的必备技术，通过消息队列完成此类数据收集是最好的选择。
6 消息中间件常⽤协议
6.1 AMQP协议
AMQP即Advanced Message Queuing Protocol,⼀个提供统⼀消息服务的应⽤层标准⾼级消息队列协议，是应⽤层协议的⼀个开放标准，为⾯向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语⾔等条件的限制。 优点：可靠、通⽤
6.2 MQTT协议
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的⼀个即时通讯协议，有可能成为物联⽹的重要组成部分。该协议⽀持所有平台，⼏乎可以把所有联⽹物品和外部连接起来，被⽤来当做传感器和致动器（⽐如通过Twitter让房屋联⽹）的通信协议。
优点：格式简洁、占⽤带宽⼩、移动端通信、PUSH、嵌⼊式系统
6.3 STOMP协议
STOMP（Streaming Text Orientated Message Protocol）是流⽂本定向消息协议，是⼀种为MOM(Message Oriented Middleware，⾯向消息的中间件)设计的简单⽂本协议。STOMP提供⼀个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进⾏交互。
优点：命令模式（⾮topic\queue模式）
6.4 XMPP协议
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语⾔（XML）的协议，多⽤于即时消息（IM）以及在线现场探测。适⽤于服务器之间的准即时操作。
核⼼是基于XML流传输，这个协议可能最终允许因特⽹⽤户向因特⽹上的其他任何⼈发送即时消息，即使其操作系统和浏览器不同。
优点：通⽤公开、兼容性强、可扩展、安全性⾼，但XML编码格式占⽤带宽⼤
6.5 其他基于TCP/IP⾃定义的协议
有些特殊框架（如：redis、kafka、zeroMq等）根据⾃⾝需要未严格遵循MQ规范，⽽是基于TCP\IP⾃⾏封装了⼀套协议，通过⽹络socket接⼝进⾏传输，实现了MQ的功能。
7 常见消息中间件MQ介绍
7.1 RocketMQ
阿⾥系下开源的⼀款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿⾥参照kafka设计思想使⽤java实现的⼀套mq。同时将阿⾥系内部多款mq产品（Notify、metaq）进⾏整合，只维护核⼼功能，去除了所有其他运⾏时依赖，保证核⼼功能最简化，在此基础上配合阿⾥上述其他开源产品实现不同场景下mq的架构，⽬前主要多⽤于订单交易系统。
具有以下特点：
能够保证严格的消息顺序
提供针对消息的过滤功能
提供丰富的消息拉取模式
黄光制程
⾼效的订阅者⽔平扩展能⼒
实时的消息订阅机制
亿级消息堆积能⼒
7.2 RabbitMQ
使⽤Erlang编写的⼀个开源的消息队列，本⾝⽀持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的⾮常重量级，更适合于企业级的开发。同时实现了Broker架构，核⼼思想是⽣产者不会将消息直接发送给队列，消息在发送给客户端时先在中⼼队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的⽀持。多⽤于进⾏企业级的ESB整合。
7.3 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等。
7.4 Redis
使⽤C语⾔开发的⼀个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是⼀个Key-Value数据库存储系统，但它本⾝⽀持MQ功能，所以完全可以当做⼀个轻量级的队列服务来使⽤。对于RabbitMQ和Redis的⼊队和出队操作，各执⾏100万次，每10万次记录⼀次执⾏时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同⼤⼩的数据。实验表明：⼊队时，当数据⽐较⼩时Redis的性能要⾼于RabbitMQ，⽽如果数据⼤⼩超过了10K，Redis则慢的⽆法忍受；出队时，⽆论数据⼤⼩，Redis都表现出⾮常好的性能，⽽RabbitMQ 的出队性能则远低于Redis。
7.5 Kafka
Apache下的⼀个⼦项⽬，使⽤scala实现的⼀个⾼性能分布式Publish/Subscribe消息队列系统，具有以下特性：快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进⾏消息持久化；
⾼吞吐：在⼀台普通的服务器上既可以达到10W/s的吞吐速率；
⾼堆积：⽀持topic下消费者较长时间离线，消息堆积量⼤；
完全的分布式系统：Broker、Producer、Consumer都原⽣⾃动⽀持分布式，依赖zookeeper⾃动实现复杂均衡；
⽀持Hadoop数据并⾏加载：对于像Hadoop的⼀样的⽇志数据和离线分析系统，但⼜要求实时处理的限制，这是⼀个可⾏的解决⽅案。
7.6 ZeroMQ
号称最快的消息队列系统，专门为⾼吞吐量/低延迟的场景开发，在⾦融界的应⽤中经常使⽤，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的⾼级/复杂的队列，但是开发⼈员需要⾃⼰组合多种技术框架，开发成本⾼。因此ZeroMQ具有⼀个独特的⾮中间件的模式，更像⼀个socket library，你不需要安装和运⾏⼀个消息服务器或中间件，因为你的应⽤程序本⾝就是使⽤ZeroMQ API完成逻辑服务的⾓⾊。但是ZeroMQ仅提供⾮持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使⽤ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层⽆关的：ZeroMQ套接字对所有传输层协议定义了统⼀的API接⼝。默认⽀
持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最⼩的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建⽴，断开和重连逻辑。
风光互补led路灯特性：
⽆锁的队列模型：对于跨线程间的交互（⽤户端和session）之间的数据交换通道pipe，采⽤⽆锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会⾃动触发读写事件。
批量处理的算法：对于批量的消息，进⾏了适应性的优化，可以批量的接收和发送消息。
多核下的线程绑定，⽆须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利⽤多核的优势，每个核绑定运⾏⼀个⼯作者线程，避免多线程之间的CPU切换开销。
⼆、主要消息中间件的⽐较
综合选择RabbitMq
纳豆菌种
转载: blog.csdn/wqc19920906/article/details/82193316
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议