1.RocketMq名词解释

TagA || TagB ||TagC

订阅topic下的TagA和TagB和TagC

1.1.1.2错误的消费方式

同一个消费者多次订阅某个 Topic 下的 Tag，以最后一次订阅的 Tag 为准：

//如下错误代码中， 只能接收到 下 TagB 的消息，而不能接收 TagA 的消息。

consumer.subscribe("MQ_TOPIC", "TagA", new MessageListener() {public Action consume(Message message, ConsumeContext context) {System.out.println(message.getMsgID());return Action.CommitMessage;}});consumer.subscribe("MQ_TOPIC", "TagB", new MessageListener() {public Action consume(Message message, ConsumeContext context) {System.out.println(message.getMsgID());return Action.CommitMessage;}});

1.2 集群消费和广播消费

1.集群：

使用相同的的消费者被认为是同一个集群。同一个集群下订阅者消费逻辑必须相同，包括Tag的使用。这些消费者逻辑上可以认为是一个消费点

2.集群消费

消息队列 认为队列中的消息只被集群中的任意订阅者消费一次支持顺序消费消费进度在服务端维护，可靠性高不能保证重复投递的消息是路由到同一台机器

3.广播消费

广播消费模式下不支持顺序消息。每条消息都需要被相同逻辑的多台机器处理。消费进度在客户端维护，出现重复的概率稍大于集群模式。广播模式下，消息队列 保证每条消息至少被每台客户端消费一次，但是并不会对消费失败的消息进行失败重投，因此业务方需要关注消费失败的情况。广播模式下，客户端第一次启动时默认从最新消息消费。客户端的消费进度是被持久化在客户端本地的隐藏文件中，因此不建议删除该隐藏文件，否则会丢失部分消息。广播模式下，每条消息都会被大量的客户端重复处理，因此推荐尽可能使用集群模式。目前仅 Java 客户端支持广播模式。广播模式下服务端不维护消费进度，所以消息队列 控制台不支持消息堆积查询和堆积报警功能。

1.3 发送普通消息（三种方式）

消息队列 发送普通消息有三种实现方式：可靠同步发送、可靠异步发送、单向（）发送。 本文介绍了每种实现的原理、使用场景以及三种实现的异同，同时提供了代码示例以供参考。

注意：顺序消息只支持可靠同步发送。

1.3.1可靠同步发送

原理：同步发送是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。

应用场景：此种方式应用场景非常广泛，例如重要通知邮件、报名短信通知、营销短信系统等。

1.3.2 可靠异步发送

原理：异步发送是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。 消息队列 的异步发送，需要用户实现异步发送回调接口（）。消息发送方在发送了一条消息后，不需要等待服务器响应即可返回，进行第二条消息发送。发送方通过回调接口接收服务器响应，并对响应结果进行处理。

应用场景：异步发送一般用于链路耗时较长，对 RT 响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等。

1.3.3 单向（）发送

原理：单向（）发送特点为发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。 此方式发送消息的过程耗时非常短，一般在微秒级别。

应用场景：适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。

1.4 消息类型

1.4.1 定时消息和延时消息

定时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 进行消费，该消息即定时消息。

延时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 进行消费，该消息即延时消息。

适用场景

定时消息和延时消息适用于以下一些场景：

消息生产和消费有时间窗口要求：比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条 延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。

通过消息触发一些定时任务，比如在某一固定时间点向用户发送提醒消息。

1.4.2 顺序消息

顺序消息（FIFO 消息）是消息队列 提供的一种严格按照顺序进行发布和消费的消息类型。 顺序消息指消息发布和消息消费都按顺序进行。

顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。顺序消费：对于指定的一个 Topic，按照一定的先后顺序接收消息，即先发送的消息一定会先被客户端接收到。

1.4.3 事务消息

消息队列 提供类似 X/Open XA 的分布事务功能，通过消息队列 事务消息能达到分布式事务的最终一致。

步骤：

发送方向消息队列 服务端发送消息。服务端将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。发送方开始执行本地事务逻辑。发送方根据本地事务执行结果向服务端提交二次确认（ 或是 ），服务端收到 状态则将半消息标记为可投递，订阅方最终将收到该消息；服务端收到 状态则删除半消息，订阅方将不会接受该消息。在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半消息进行操作

1.5 消息重试

1.5.1 顺序消息的重试

1.4 消息类型

1.4.1 定时消息和延时消息

定时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 进行消费，该消息即定时消息。

延时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 进行消费，该消息即延时消息。

适用场景

定时消息和延时消息适用于以下一些场景：

消息生产和消费有时间窗口要求：比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条 延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。

通过消息触发一些定时任务，比如在某一固定时间点向用户发送提醒消息。

1.4 消息类型

1.4.1 定时消息和延时消息

定时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 进行消费，该消息即定时消息。

延时消息：

将消息发送到消息队列 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 进行消费，该消息即延时消息。

适用场景

定时消息和延时消息适用于以下一些场景：

消息生产和消费有时间窗口要求：比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条 延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。

通过消息触发一些定时任务，比如在某一固定时间点向用户发送提醒消息。

1.4.2 顺序消息

顺序消息（FIFO 消息）是消息队列 提供的一种严格按照顺序进行发布和消费的消息类型。 顺序消息指消息发布和消息消费都按顺序进行。

顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。顺序消费：对于指定的一个 Topic，按照一定的先后顺序接收消息，即先发送的消息一定会先被客户端接收到。

1.4.3 事务消息

消息队列 提供类似 X/Open XA 的分布事务功能，通过消息队列 事务消息能达到分布式事务的最终一致。

步骤：

发送方向消息队列 服务端发送消息。服务端将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。发送方开始执行本地事务逻辑。发送方根据本地事务执行结果向服务端提交二次确认（ 或是 ），服务端收到 状态则将半消息标记为可投递，订阅方最终将收到该消息；服务端收到 状态则删除半消息，订阅方将不会接受该消息。在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半消息进行操作

1.5 消息重试

1.5.1 顺序消息的重试

对于顺序消息，当消费者消费消息失败后，消息队列 会自动不断进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。因此，建议您使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。

1.5.2无序消息的重试

对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。

无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。

如果消息重试 16 次后仍然失败，消息将不再投递。如果严格按照上述重试时间间隔计算，某条消息在一直消费失败的前提下，将会在接下来的 4 小时 46 分钟之内进行 16 次重试，超过这个时间范围消息将不再重试投递。

注意： 一条消息无论重试多少次，这些重试消息的 ID 不会改变。

1.6 消息幂等性

消息队列 消费者在接收到消息以后，有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。因为 ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以 ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置

原因：

发送时消息重复：当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且 ID 也相同的消息。

投递时消息重复：消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 ID 也相同的消息。

1.7 消费轨迹

消息队列 系统中，一条消息的完整链路包含生产方、服务方、消费方三个角色，每个角色处理消息的过程中都会在轨迹链路中增加相关的信息，将这些信息汇聚即可获取任意消息当前的状态，从而为生产环境中的问题排查提供强有力的数据支持。

消息轨迹的数据包含：

1.8 消息堆积

已经将消息发送到消息队列 的服务端，但由于 消费能力有限，未能在短时间内将所有消息正确消费掉，此时在消息队列 的服务端保存着未被消费的消息，该状态即消息堆积。要想跳过堆积消息，可以设置重置消费点

1.9 死信队列

死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

消息队列 将这种正常情况下无法被消费的消息称为死信消息（Dead- ），将存储死信消息的特殊队列称为死信队列（Dead- Queue）。

死信消息具有以下特性：

不会再被消费者正常消费。有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，请在死信产生后的 3 天内及时处理

1.10 重试机制

1.10.1 生产端重试

如果由于网络抖动等原因，程序向发送消息时没有成功，即发送端没有收到的ACK，导致最终无法消费消息，此时会自动进行重试。

1.10.2 消费端重试

异常重试：由于端逻辑出现了异常，导致返回了状态，那么就会在一段时间后尝试重试。超时重试：如果端处理时间过长，或者由于某些原因线程挂起，导致迟迟没有返回消费状态，就会认为消费超时，此时会发起超时重试。