更新时间:2020-12-29 18:28
与快速开始相关的常见问题如下:
暂不支持,消息的生产者和消费者需要和消息队列所在的 region 网络处于联通状态。
Action.ReconsumerLater
,或者 NULL,或者抛出异常,消息都会走重试流程,至多重试 16 次,如果重试 16 次后,仍然失败,则消息丢弃。每次重试的间隔时间如下:第几次重试 | 每次重试间隔时间 |
---|---|
1 | 10 秒 |
2 | 30 秒 |
3 | 1 分钟 |
4 | 2 分钟 |
5 | 3 分钟 |
6 | 4 分钟 |
7 | 5 分钟 |
8 | 6 分钟 |
9 | 7 分钟 |
10 | 8 分钟 |
11 | 9 分钟 |
12 | 10 分钟 |
13 | 20 分钟 |
14 | 30 分钟 |
15 | 1 小时 |
16 | 2 小时 |
可以通过调用 message.getReconsumeTimes() 方法来获取消息的重试次数。
消息队列提供了多种 消息查询 方式:
绝大多数情况下,消息是不重复的。作为一款分布式消息中间件,在网络抖动、应用处理超时等异常情况下,无法保证消息不重复,但是能保证消息不丢失。
是。
消息生产者将所有类型的 Tag 都发送至同一个 Topic 中,消息按照先后顺序在队列中排列,并维护一个消息写入位点;Group ID 启动时会指明需要订阅的 Tag,并从服务端获取当前的消费位点;服务端从当前 Group ID 的消费位点开始遍历队列中的消息,判断如果消息的 Tag 符合 Group ID 订阅的 Tag 即投递给 Group ID,不符合则跳过该消息。
如下图所示,Group ID 消费位点往前移动,Tag2、Tag3 的消息会在服务端被过滤掉,Tag1 的消息为 Group ID 所需要的,会投递给 Group ID。
因此您在控制台的 消费者状态 > 消息堆积总量 看到的是未被过滤的堆积总量,包含了所有 Tag 的消息量。
在文档使用中是否遇到以下问题
更多建议
匿名提交