一。MQ的工作原理(图见附件)

首先来看本地通讯的情况，应用程序A和应用程序B运行于同一系统A，它们之间可以借助消息队列技术进行彼此的通讯：应用程序A向队列1发送一条信息，而当应用程序B需要时就可以得到该信息。
其次是远程通讯的情况，如果信息传输的目标改为在系统B上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列2发送一条信息，系统A的MQ发现Q2所指向的目的队列实际上位于系统B，它将信息放到本地的一个特殊队列－传输队列(Transmission Queue)。我们建立一条从系统A到系统B的消息通道，消息通道代理将从传输队列中读取消息，并传递这条信息到系统B，然后等待确认。只有MQ接到系统B成功收到信息的确认之后，它才从传输队列中真正将该信息删除。如果通讯线路不通，或系统B不在运行，信息会留在传输队列中，直到被成功地传送到目的地。这是MQ最基本而最重要的技术–确保信息传输，并且是一次且仅一次(once-and-only-once)的传递。
MQ提供了用于应用集成的松耦合的连接方法，因为共享信息的应用不需要知道彼此物理位置（网络地址）；不需要知道彼此间怎样建立通信；不需要同时处于运行状态；不需要在同样的操作系统或网络环境下运行。

MQ的基本配置举例
在上图中，要实现网络上两台主机上的通讯，若采用点对点的通讯方式，我们至少要建立如下MQ的对象：
在发送方A:
1）建立队列管理器QMA: crtmqm -q QMA
2）定义本地传输队列: define qlocal (QMB) usage (xmitq) defpsist(yes)
3）创建远程队列: define qremote (QR.TOB) rname (LQB) rqmname (QMB) xmitq (QMB)
4）定义发送通道: define channel (A.TO.B) chltype (sdr) conname (‘IP of B’) xmitq (QMB) + trptype (tcp)

在接收方B：
1）建立队列管理器QMB: crtmqm -q QMB
2）定义本地队列QLB: define qlocal (LQB)
3）创建接收通道: define channel (A.TO.B) chltype (rcvr) trptype (tcp)
经过上述配置，我们就可以实现从主机A到B的单向通讯，若要实现二者之间的双向通讯，可参考此例创建所需要的MQ对象。

MQ的通讯模式

点对点通讯：点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。
多点广播：MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。
发布/订阅(Publish/Subscribe)模式：发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。在MQ家族产品中，MQ Event Broker是专门用于使用发布/订阅技术进行数据通讯的产品，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。
群集(Cluster)：为了简化点对点通讯模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。

二。看到一个mq比较好的比喻…

**
个人认为消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。所以主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时由于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦和。

使用场景的话，举个例子：
假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作：
校验用户名等信息，如果没问题会在数据库中添加一个用户记录
如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
发送给用户一个包含操作指南的系统通知
等等……
但是对于用户来说，注册功能实际只需要第一步，只要服务端将他的账户信息存到数据库中他便可以登录上去做他想做的事情了。至于其他的事情，非要在这一次请求中全部完成么？值得用户浪费时间等你处理这些对他来说无关紧要的事情么？所以实际当第一步做完后，服务端就可以把其他的操作放入对应的消息队列中然后马上返回用户结果，由消息队列异步的进行这些操作。

或者还有一种情况，同时有大量用户注册你的软件，再高并发情况下注册请求开始出现一些问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户数据记录很快的添加到数据库中了，但是却卡在发邮件或分析信息时的情况，导致请求的响应时间大幅增长，甚至出现超时，这就有点不划算了。面对这种情况一般也是将这些操作放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时可以很快的完成注册请求，不会影响用户使用其他功能。

小红是小明的姐姐.

小红希望小明多读书，常寻找好书给小明看，之前的方式是这样：小红问小明什么时候有空，把书给小明送去，并亲眼监督小明读完书才走。

久而久之，两人都觉得麻烦。后来的方式改成了：小红对小明说「我放到书架上的书你都要看」，然后小红每次发现不错的书都放到书架上，小明则看到书架上有书就拿下来看。

书架就是一个消息队列，小红是生产者，小明是消费者。

这带来的好处有：

1.小红想给小明书的时候，不必问小明什么时候有空，亲手把书交给他了，小红只把书放到书架上就行了。这样小红小明的时间都更自由。

2.小红相信小明的读书自觉和读书能力，不必亲眼观察小明的读书过程，小红只要做一个放书的动作，很节省时间。

3.当明天有另一个爱读书的小伙伴小强加入，小红仍旧只需要把书放到书架上，小明和小强从书架上取书即可（唔，姑且设定成多个人取一本书可以每人取走一本吧，可能是拷贝电子书或复印，暂不考虑版权问题）。

4.书架上的书放在那里，小明阅读速度快就早点看完，阅读速度慢就晚点看完，没关系，比起小红把书递给小明并监督小明读完的方式，小明的压力会小一些。

这就是消息队列的四大好处：

1.解耦

每个成员不必受其他成员影响，可以更独立自主，只通过一个简单的容器来联系。

小红甚至可以不知道从书架上取书的是谁，小明也可以不知道往书架上放书的人是谁，在他们眼里，都只有书架，没有对方。

毫无疑问，与一个简单的容器打交道，比与复杂的人打交道容易一万倍，小红小明可以自由自在地追求各自的人生。

2.提速

小红选择相信「把书放到书架上，别的我不问」，为自己节省了大量时间。

小红很忙，只能抽出五分钟时间，但这时间足够把书放到书架上了。

3.广播

小红只需要劳动一次，就可以让多个小伙伴有书可读，这大大地节省了她的时间，也让新的小伙伴的加入成本很低。

4.削峰

假设小明读书很慢，如果采用小红每给一本书都监督小明读完的方式，小明有压力，小红也不耐烦。

反正小红给书的频率也不稳定，如果今明两天连给了五本，之后隔三个月才又给一本，那小明只要在三个月内从书架上陆续取走五本书读完就行了，压力就不那么大了。

当然，使用消息队列也有其成本：

1.引入复杂度

毫无疑问，「书架」这东西是多出来的，需要地方放它，还需要防盗。

2.暂时的不一致性

假如妈妈问小红「小明最近读了什么书」，在以前的方式里，小红因为亲眼监督小明读完书了，可以底气十足地告诉妈妈，但新的方式里，小红回答妈妈之后会心想「小明应该会很快看完吧……

这中间存在着一段「妈妈认为小明看了某书，而小明其实还没看」的时期，当然，小明最终的阅读状态与妈妈的认知会是一致的，这就是所谓的「最终一致性」。

那么，该使用消息队列的情况需要满足什么条件呢？

1.生产者不需要从消费者处获得反馈

引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层的动作还没做，上层却当成动作做完了继续往后走——即所谓异步——成为了可能。

小红放完书之后小明到底看了没有，小红根本不问，她默认他是看了，否则就只能用原来的方法监督到看完了。

2.容许短暂的不一致性

妈妈可能会发现「有时候据说小明看了某书，但事实上他还没看」，只要妈妈满意于「反正他最后看了就行」，异步处理就没问题。

如果妈妈对这情况不能容忍，对小红大发雷霆，小红也就不敢用书架方式了。

3.确实是用了有效果

即解耦、提速、广播、削峰这些方面的收益，超过放置书架、监控书架这些成本。

否则如果是盲目照搬，「听说老赵家买了书架，咱们家也买一个」，买回来却没什么用，只是让步骤变多了，还不如直接把书递给对方呢，那就不对了。

消息队列MQ技术的介绍和原理相关推荐

消息队列MQ技术介绍
一. 消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用耦合.异步消息.流量削锋等问题.实现高性能.高可用.可伸缩和最终一致性架构.是大型分布式系统不可缺少的中间件. 目前在生产环境, ...
后端技术：消息队列MQ/JMS/Kafka相关知识介绍
?今天给大家分享消息队列MQ/JMS/Kafka相关知识介绍 1.消息队列介绍首先举个收快递的栗子,传统的收快递,快递小哥把我们的快递送到我们的手里.他需要什么条件嗯? 快递小哥有时间送, 我们有时 ...
java队列_RPC远程调用和消息队列MQ的区别
RPC和MQ同样都是用于分布式系统的两个很重要的技术,都有服务提供者.消费者的概念,可在一定程度上对系统进行解耦.但两者之间还是有区别的,本篇简单介绍~ 一.RPC RPC(Remote Proced ...
面试官：消息队列 MQ/ JMS/ Kafka 有什么区别？
更多架构干货请关注公众号"架构之路".是不是平常听到说消息队列啊,JMS啊,MQ啊 .kafka啊巴啦啦的一堆术语,听不懂?关系混乱?今天就让我们来一起来看看他们都是什么吧. 1消 ...
Kafka，ActiveMQ，RabbitMQ等消息队列使用的场景介绍
点击上方"后端技术精选",选择"置顶公众号" 技术文章第一时间送达! 作者:cws1214 blog.csdn.net/cws1214/article/deta ...
梳理消息队列 MQ/JMS/Kafka
是不是平常听到说消息队列啊,JMS啊,MQ啊 .kafka啊巴啦啦的一堆术语,听不懂?关系混乱?今天就让我们来一起来看看他们都是什么吧. 1消息队列介绍首先举个收快递的栗子,传统的收快递,快递小哥把 ...
消息队列MQ/JMS/Kafka，你都了解多少？
今日推荐isEmpty 和 isBlank 的用法区别,你都知道吗?SpringBoot项目优化和Jvm调优(楼主亲测,真实有效)国内大神成功给手机装上了 Win11,代码已开源!Fluent Myb ...
消息队列的使用场景_消息队列MQ的特点、选型及应用场景
一.什么是消息队列消息队列(Message Queue,简称MQ),指保存消息的一个容器,本质是个队列. 消息(Message)是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可 ...
详解RPC远程调用和消息队列MQ的区别
谈到分布式架构,就不得不谈到分布式架构的基石RPC. 什么是RPC RPC(Remote Procedure Call)远程过程调用,主要解决远程通信间的问题,不需要了解底层网络的通信机制. RPC服 ...
消息中间件系列(四)：消息队列MQ的特点、选型、及应用场景详解
前面集中谈了分布式缓存Redis系列: 高并发架构系列:分布式锁的由来.特点.及Redis分布式锁的实现详解高并发架构系列:Redis并发竞争key的解决方案详解高并发架构系列:Redis缓存和M ...

消息队列MQ技术的介绍和原理

一。MQ的工作原理(图见附件)

二。看到一个mq比较好的比喻…

消息队列MQ技术的介绍和原理相关推荐

最新文章

热门文章