上云无忧 > 文档中心 > 腾讯云消息队列 Pulsar 版 - 定时和延时消息
消息队列 Pulsar 版
腾讯云消息队列 Pulsar 版 - 定时和延时消息

文档简介:
相关概念: 定时消息:消息在发送至服务端后,实际业务并不希望消费端马上收到这条消息,而是推迟到某个时间点被消费,这类消息统称为定时消息。 延时消息:消息在发送至服务端后,实际业务并不希望消费端马上收到这条消息,而是推迟一段时间后再被消费,这类消息统称为延时消息。
*此产品及展示信息均由腾讯云官方提供。免费试用 咨询热线:400-826-7010,为您提供专业的售前咨询,让您快速了解云产品,助您轻松上云! 微信咨询
  免费试用、价格特惠

相关概念

定时消息:消息在发送至服务端后,实际业务并不希望消费端马上收到这条消息,而是推迟到某个时间点被消费,这类消息统称为定时消息。
延时消息:消息在发送至服务端后,实际业务并不希望消费端马上收到这条消息,而是推迟一段时间后再被消费,这类消息统称为延时消息。
实际上,定时消息可以看成是延时消息的一种特殊用法,其实现的最终效果和延时消息是一致的。

适用场景

如果系统是一个单体架构,则通过业务代码自己实现延时或利用第三方组件实现基本没有差别;一旦架构复杂起来,形成了一个大型分布式系统,有几十上百个微服务,这时通过应用自己实现定时逻辑会带来各种问题。一旦运行着延时程序的某个节点出现问题,整个延时的逻辑都会受到影响。
针对以上问题,利用延时消息的特性投递到消息队列里,便是一个较好的解决方案,能统一计算延时时间,同时重试和死信机制确保消息不丢失。
具体场景的示例如下:
微信红包发出后,生产端发送一条延时24小时的消息,到了24小时消费端程序收到消息,进行用户是否已经领走红包的判断,如果没有则退还到原账户。
小程序下单某商品后,后台存放一条延时30分钟的消息,到时间之后消费端收到消息触发对支付结果的判断,如果没有支付就取消订单,这样就实现了超过30分钟未完成支付就取消订单的逻辑。
微信上用户将某条信息设置待办后,也可以通过发送一条定时消息,服务端到点主动消费这条定时消息,对用户进行待办项提醒。

使用方式

在 TDMQ Pulsar 版的 SDK 中提供了专门的 API 来实现定时消息和延时消息。
对于定时消息,您需要提供一个消息发送的时刻。
对于延时消息,您需要提供一个时间长度作为延时的时长。

定时消息

定时消息通过生产者producer的 deliverAt() 方法实现,代码示例如下:
		
String value = "message content";
try {
//需要先将显式的时间转换为 Timestamp
long timeStamp = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse("2020-11-11 00:00:00").getTime();
//通过调用 producer 的 deliverAt 方法来实现定时消息
MessageId msgId = producer.newMessage()
.value(value.getBytes())
.deliverAt(timeStamp)
.send();
} catch (ParseException e) {
//TODO 添加对 Timestamp 解析失败的处理方法
e.printStackTrace();
}
注意
定时消息的时间范围为当前时间开始计算,864000秒(10天)以内的任意时刻。如10月1日12:00开始,最长可以设置到10月11日12:00。
定时消息不可以使用 batch 模式发送,请在创建 producer 的时候把 enableBatch 参数设为 false
定时消息的消费模式仅支持使用 Shared 模式进行消费,否则会失去定时效果(Key-shared 也不支持)。

延时消息

延时消息通过生产者produce的 deliverAfter() 方法实现,代码示例如下:
		
String value = "message content";
//需要指定延时的时长
long delayTime = 10L;
//通过调用 producer 的 deliverAfter 方法来实现定时消息
MessageId msgId = producer.newMessage()
.value(value.getBytes())
.deliverAfter(delayTime, TimeUnit.SECONDS) //单位可以自由选择
.send();
注意
延时消息的时长取值范围为0 - 864000秒(0秒 - 10天)。如10月1日12:00开始,最长可以设置864000秒。
Go SDK 当延时消息时间超过 10 天时,将可能出现重复消息的情况。
延时消息不可以使用 batch 模式发送,请在创建 producer 的时候把 enableBatch 参数设为 false
延时消息的消费模式仅支持使用 Shared 模式进行消费,否则会失去延时效果(Key-shared 也不支持)。

使用说明和限制

使用定时或延迟消息时,建议与普通消息使用不同的 Topic 来管理,即定时与延迟消息发送到一个固定的 Topic,普通消息发送到另一个 Topic 中,方便后续的管理与维护,增加稳定性。
使用定时和延时两种类型的消息时,请确保客户端的机器时钟和服务端的机器时钟(所有地域均为UTC+8 北京时间)保持一致,否则会有时差。
定时和延时消息在精度上会有1秒左右的偏差。
定时和延时消息不支持 batch 模式(批量发送),batch 模式会引起消息堆积,保险起见,请在创建 producer 的时候把 enableBatch 参数设为 false
定时和延时消息的消费模式仅支持使用 Shared 模式进行消费,否则会失去定时或延时效果(Key-shared 也不支持)。
关于定时和延时消息的时间范围,最大均为10天。
使用定时消息时,设置的时刻在当前时刻以后才会有定时效果,否则消息将被立即发送给消费者。
设定定时时间后,TTL 的时间依旧会从发送消息的时间点开始算消息的最长保留时间;例如定时到2天后发送,消息最长保留(TTL)如果设置为1天的话,则消息在1天后会被删除,这个时候要确保 TTL 的时间要大于延时的时间,即 TTL 设置成大于等于2天,否则 TTL 到期时,消息会被删除。延时消息同理。
普通类型 Topic 支持收发定时/延时消息,调用 使用方式 中的 API 即可发送定时/延时消息。

相似文档
  • 本文主要介绍 TDMQ Pulsar 版中消息标签过滤的功能、应用场景和使用方式。 功能介绍: Tag,即消息标签,用于对某个Topic下的消息进行分类。TDMQ Pulsar 版的生产者在发送消息时,指定消息的 Tag,消费者需根据已经指定的 Tag 来进行订阅。
  • 重试 Topic 是一种为了确保消息被正常消费而设计的 Topic 。当某些消息第一次被消费者消费后,没有得到正常的回应,则会进入重试 Topic 中,当重试达到一定次数后,停止重试,投递到死信 Topic 中。
  • 本文主要介绍 TDMQ Pulsar 客户端与连接、客户端与生产/消费者之间的关系,并向开发者介绍客户端合理的使用方式,以便更高效、稳定地使用 TDMQ Pulsar 版的服务。
  • 操作场景: 集群是 TDMQ Pulsar 版中的一个资源维度,不同集群的命名空间、Topic、角色权限等完全隔离。每个集群会有集群的资源限制例如 Topic 总数、消息保留时长等。常见的使用方式如:开发测试环境使用一个专门集群,生产环境使用一个专门的集群。
  • 操作场景: 如当前的集群规格不满足您的业务需求,您可以在控制台上提升您的集群规格和存储规格。 说明: 当前仅专业集群支持升级集群规格,虚拟集群暂不支持升配。升级过程中理论上对业务无感,但随着服务端 Rebalance Topic 流量时,客户端可能会出现断开重连的现象。
官方微信
联系客服
400-826-7010
7x24小时客服热线
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部