mq查询对端地址

1、首先确定发送方的MQ服务器地址。
2、其次确定对端的MQ服务器地址，确定发送到的队列名。
3、最后使用MQ客户端API（例如IBMMQ的JavaAPI）连接到MQ服务器，并使用API中提供的方法发送消息到指定的队列，即可成功查询对端地址。

队列是一种先进先出的数据结构。

线性数据结构：
常用的：线性表、栈、队列、串等
非线性数据结构：
常用的：数组、广义表、树结构、图结构、堆

消息队列就是基础数据结构中的“先进先出”的一种数据结构。生活中的排队，先排的人先得到，就是典型的“先进先出”。

以我们的药房系统为例，有商品系统、订单系统、物流系统、支付系统等，用户下单后如果耦合的去调用各个系统，那么如果一个系统出现问题，下单的 *** 作就无法完成。
当用消息队列的方式后，如果物流系统出现问题，需要时间去修复，但是我的下单 *** 作是不受影响的，用户依然可以下单，当物流问题修复后，可以继续物流的 *** 作。

A调用B，B处理需要较长的时间，所以A不能一直等待B，但是又需要B的处理结果。之前的做法一般是给B一个callback。B处理完后回调A。
这时候用消息队列的话，A调用B，B处理完后，发消息给mq,mq再将消息转给A。

假设每秒有3000个请求同步消息，只有两台机器，每台每秒只能处理1000个请求，那多出来的请求就会把系统弄崩溃。
这时候用消息队列的方式，请求都打到消息队列里，两台机器根据自己的能够处理的请求数去消息队列中拿数据，这样即便有每秒有8000个请求，那只是把请求放在消息队列中，去拿消息队列的消息由系统自己去控制，这样就不会把整个系统给搞崩。

生产者将数据放到消息队列中，消息队列有数据了，主动叫消费者去拿(俗称push)
消费者不断去轮训消息队列，看看有没有新的数据，如果有就消费(俗称pull)

无论是我们使用消息队列来做解耦、异步还是削峰，消息队列肯定不能是单机的，所以都得是集群/分布式的。
在集群模式的部署方式中，Master与Slave配对是通过指定相同的brokerName参数来配对，Master的BrokerId必须是0，Slave的BrokerId必须是大于0的数。一个Master下面可以挂载多个Slave，同一个Master下的多个Slave通过指定不同的BrokerId来区分。有4种部署方式：

在集群模式下，为了保证高可用，必须要保证备用Broker与主用Broker信息是一致的，在备用Broker初始化时设置的了定时任务，每个60秒调用SlaveSynchronizesyncAll()方法发起向主用Broker进行一次config类文件的同步，而消息数据的同步由主备Broker通过心跳检测的方式完成，每隔5秒进行一次心跳。 主用Broker提供读写服务，而备用Broker只提供读服务。

A系统发送完消息，不管其他系统是否成功，是不对的。
两个方案：
A系统接收其它系统处理结果的mq消息回执
其它系统提供一个接口，用于A系统主动去查其处理结果。
消息幂等
对于确保消息在生产者和消费者之间进行传输而言一般有三种传输保障（delivery guarantee）：At most once，至多一次，消息可能丢失，但绝不会重复传输；At least once，至少一次，消息绝不会丢，但是可能会重复；Exactly once，精确一次，每条消息肯定会被传输一次且仅一次。对于大多数消息中间件而言，一般只提供 At most once 和 At least once 两种传输保障，对于第三种一般很难做到，由此消息幂等性也很难保证
全局幂等：
如以订单号为唯一标识，下游服务设置一个去重。

解决方案：分布式事务

将数据写到消息队列上，系统B和C还没来得及取消息队列的数据，服务就挂了。如果没有做任何的措施，我们的数据就丢了。
所以需要数据持久化。
同步刷盘：在消息到达MQ后，RocketMQ需要将数据持久化，同步刷盘是指数据到达内存之后，必须刷到commitlog日志之后才算成功，然后返回producer数据已经发送成功。
异步刷盘：是指数据到达内存之后,返回producer说数据已经发送成功。，然后再写入commitlog日志。
commitlog：
commitlog就是来存储所有的元信息，包含消息体，类似于Mysql、Oracle的redolog,所以主要有CommitLog在，Consume Queue即使数据丢失，仍然可以恢复出来。
consumequeue：记录数据的位置,以便Consume快速通过consumequeue找到commitlog中的数据

简单的例子，有一条数据，先执行了修改，后执行了删除，并且都发送到了你自己的那个消息队列中，如果不按照顺序读，先读取了删除，再读取修改就会出现问题。

RocketMQ是一款分布式、队列模型的消息中间件，具有以下特点：

1、支持严格的消息顺序；

2、支持Topic与Queue两种模式；

3、亿级消息堆积能力；

4、比较友好的分布式特性；

5、同时支持Push与Pull方式消费消息

参考文献： >可以在windows下的MQ队列管理器中点右键选择“显示队列管理器”，打开后选择“显示远程队列管理器”，输入远程LINUX下的队列管理器名称和远程LIUNX系统的IP地址，就可以查看了。

MQ
IBM MQ 介绍
消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、 *** 作系统以及通信协议的网络彼此进行通信。例如，IBM WebSphere MQ 支持 35 种以上的不同 *** 作系统。
IBM WebSphere MQ 支持两种不同的应用程序编程接口：Java 消息服务（JMS）和消息队列接口（MQI）。在 IBM WebSphere MQ 服务器上，JMS 绑定方式被映射到 MQI。如图 3 所示，应用程序直接与其本地队列管理器通过使用 MQI 进行对话，MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供 13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口，因为大部分艰苦工作都将透明完成的。
图形 2 IBM WebSphere MQ 编程
图 2 显示了 IBM WebSphere MQ 编程的原理。第一步是让应用程序与队列管理器连接。它通过 MQConnect 调用来进行此连接。下一步使用 MQOpen 调用为输出打开一个队列。然后应用程序使用 MQPut 调用将其数据放到队列上。要接收数据，应用程序调用 MQOpen 调用打开输入队列。应用程序使用 MQGet 调用从队列上接收数据。
图中还显示了消息通道代理（MCA）、通道出口和对象权限管理器（OAM）。MCA 是 IBM WebSphere MQ 程序，它使用现有传输服务诸如 TCP/IP 与 SNA 将消息从本地传输队列移到目标队列管理器。这些传输服务即通道。通道出口是用户写入库，可以在通道运作期间，从已定义位置号之一进入这些库。OAM 是命令和对象管理的缺省授权服务（针对 *** 作系统）。这三个组件对 IBM WebSphere MQ 的现有安全性解决方案非常重要。

在linux中，程序的加载，涉及到两个工具，linker 和loader。Linker主要涉及动态链接库的使用，loader主要涉及软件的加载。 exec执行一个程序 elf为现在非常流行的可执行文件的格式，它为程序运行划分了两个段，一个段是可以执行的代码段

生产者将消息投递到交换器，然后交换器再将消息路由到一个或者多个队列中。
RabbitMQ 定义了4种类型的交换器：

在使用交换器之前，需要先创建交换器，RabbitMQ 的 Java 客户端提供了 exchangeDeclare() 方法来声明交换器。

参数说明：

返回值：

方法重载：

有创建就会有删除，RabbitMQ 的 Java 客户端提供了 exchangeDelete() 方法来删除交换器。

参数说明：

返回值：

exchangeDeclarePassive() 方法用来检测交换器是否存在。如果存在，则正常返回；如果不存在，则抛出异常 404 channel exception

队列在 RabbitMQ 中用来存储消息，队列通过 BindingKey 与 交换器相互绑定。

与 exchangeDeclare() 方法相比， queueDeclare() 的重载方法少很多，只有两个重载方法：

参数说明：

返回值：

与交换器一样，队列也可以删除

参数说明：

返回值：

---