什么是消息中间件？通过提供某种规范实现在不同系统之间传递语义准确的消息。专注于数据的发送和接收，利用高效可靠的异步消息传递机制的集成分布式系统。什么是MQ?

MQ全称为Message Queue, 消息队列(MQ)是应用程序“对”应用程序的通信方法，也是消息中间件的一种。

MQ：生产者往消息队列中写消息，消费者可以读取队列中的消息。

消息队列的应用场景

a. 异步处理：比如订单状态处理完毕的回调通知；

b. 系统间应用解耦：前一个系统将要处理的内容放入消息队列，就不再关心后续的其他操作了，后面的系统获取消进行消费；

c. 流量削锋：避免因流量过大，导致流量暴增，海量消息堆积，应用挂掉；

d. 日志处理：通过队列进行日志处理；

e. 消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。

基本概念

1

消息模型

点对点模型(P2P)：

在P2P模型中，有下列概念：消息队列(Queue)、发送者(Sender)、接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到它们被消费或超时。

·每个消息只有一个消费者(Consumer)(即一旦被消费，消息就不再在消息队列中)。

·发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列。

·接收者在成功接收消息之后需向队列应答成功。

如果希望发送的每个消息都应该被成功处理的话，那么你需要P2P模型。

发布-订阅模型(Pub/Sub)：

在Pub/Sub模型中，有下列概念：主题(Topic)、发布者(Publisher)、订阅者(Subscriber)。客户端将消息发送到主题。多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

·每个消息可以有多个消费者

·发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅之后，才能消费发布者的消息，而且，为了消费消息，订阅者必须保持运行的状态。

订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活(运行)，它也能接收到发布者的消息。

如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。

2

交互原理

Nameserver做什么？

Namesrv是主要做路由服务(状态服务器)，无状态可集群横向扩展。broker同时向多个Namesrv机器上报broker机器的实时状态信息、topic消息队列路由信息、broker基础信息、集群信息，从而达到数据热备份的作用。Producer发送消息的时候，先请求nanesrv获取topic路由信息，然后根据topic路由信息路由到broker(topic是存储在broker)。Consumer消费消息的时候同样先请求nanesrv获取topic路由信息，然后根据topic路由信息路由到broker。

Broker做什么？

消息中转角色，负责存储消息，转发消息。broker部署相对复杂，分为master和slave，一个master可以对应多个slave，但一个slave只能对应一个master(支持异步复制和半同步复制)。master可以集群部署，通过同样的ClusterName来区分，同一个集群中的BrokerName不能一样。每个broker与namesrv集群中的所有节点建立长连接，定时发送心跳信息(30秒)，注册topic等信息到所有namesrv。

Producer

Producer 与Name Server 集群中的其中一个节点(随机选择)建立长连接，定期从Name Server 取Topic 路由信息，并向提供Topic 服务的Master 建立长连接，且定时向Master 发送心跳，Slave会同步Master的信息。Producer 完全无状态，可集群部署。

Consumer

Consumer与Name Server 集群中的其中一个节点(随机选择)建立长连接，定期从Name Server 取Topic 路由信息，并向提供Topic 服务的Master、Slave 建立长连接，且定时向Master、Slave 发送心跳。Consumer既可以从Master 订阅消息，也可以从Slave 订阅消息，订阅规则由Broker 配置决定。

Broker集群

一个Master下面可以挂载多个Slave，同一Master下的多个Slave通过指定不同的BrokerId来区分。

3

测试内容及问题排查方法

Q1：MQ是否能保证消息不重复？

1、绝大多数情况下，消息是不重复的。作为一款分布式消息中间件，在网络抖动、应用处理超时等异常情况下，无法保证消息不重复，但是能保证消息不丢失；

2、需要业务方自己实现去重逻辑，不推荐使用msgid来做去重，因为msgid在绝大部分情况下，是不会重复，不排除极端情况可能会出现重复，或者多个集群之间出现重复msgid；

3、可以使用订单编号等唯一的作为唯一标识来去重。

Q2：MQ未被消费、消息发送了，但是没有收到怎么查询？

MQ提供了多种消息查询方式：

1、使用Topic按时间范围进行查询，可以查询到一段时间内某Topic收到的所有消息；

2、使用Topic和MessageID对消息进行精准查询；

3、使用Topic和MessageKey较为精准地查询具有相同MessageKey的一类消息。

Q3：MQ消费失败如何重新消费消息？

1、消费业务逻辑代码如果返回ConsumeConcurrentlyStatus.RECONSUME_LATER，或者NULL，或者抛出异常，消息都会走重试流程，默认重试16次(重试次数可以自定义)，如果重试16次后，仍然失败，则消息丢弃；

2、消息重试间隔可以通过context控制，如果不控制，会越来越长。

Q4：MQ消费失败、容器环境消息消费失败怎么排查？

1.、检查订阅关系是否正确，topic是否正确；

2、检查消费组状态是否正常；

sh[用户名]consumerConnection-n127.0.0.1:9876-g消费组名

sh[用户名]consumerProgress-n127.0.0.1:9876-g消费组名

3、检查生产者机器和消费者机器的地址解析是否为容器组mq地址；在docker管理平台，模板配置中进行配置及查看；

4、检查消费者服务器是否配置了外网地址，导致消息发送到基准环境；

5、确认生产者已生产消息。

Q5：简单的日志查询

通过MQ服务器上log日志，查询put及pull的记录。

Q6：MQ消费先于同步返回

一般采用加锁机制处理。

4

命名规范

Topic命名规范：

1、所有Topic必须使用T_开头，Topic中包含业务系统，可以唯一区分业务。

2、必须填写tag，同一Topic用不同的tag区分，全部大写。消费者通过Topic+tag消费消息。

3、使用运维平台查询Topic是否存在，存在需要考虑是否要更换Topic。

例：topic：T_LOAN_PRODUCT

tag：T_CANCEL_BORROW或T_SUBMIT_RESALE[topic+tag匹配消费消息]

消费组命名规范：

1、消费组必须以S_开头，包含业务系统，全部大写。同一Topic可以被多个消费组消费。

2、使用运维平台查询消费组是否存在，存在需要考虑是否要更换消费组。

例：c-group-id:S_PFD_T_ATM

生产组命名规范：

生产者必须使用P_开头,包含业务系统，全部大写，不同的系统禁止使用同一个组名。

例：p-group-id:P_PAYFUND

链接：https://zhuanlan.zhihu.com/p/99616947

本文为51Testing经授权转载，转载文章所包含的文字来源于作者。如因内容或版权等问题，请联系51Testing进行删除

推荐阅读

点击阅读☞从业多年测试工程师总结，大厂面试必问问题就是这些

点击阅读☞那些年！测试工程师面试时都遇到过哪些问题呢？

点击阅读☞中高级测试工程师面试题，助你一臂之力！

点击阅读☞涨薪失败，我是如何从3500加班狗做到测试开发工程师的？

点击阅读☞软件测试工程师面试如何做好自我介绍？

戳