一、相关概念
·定时消息：消息在发送至服务端后，实际业务并不希望消费端马上收到这条消息，而是推迟到某个时间点被消费，这类消息统称为定时消息。
·延时消息：消息在发送至服务端后，实际业务并不希望消费端马上收到这条消息，而是推迟一段时间后再被消费，这类消息统称为延时消息。
二、适用场景
如果系统是一个单体架构，则通过业务代码自己实现延时或利用第三方组件实现基本没有差别；一旦架构复杂起来，形成了一个大型分布式系统，有几十上百个微服务，这时通过应用自己实现定时逻辑会带来各种问题。一旦运行着延时程序的某个节点出现问题，整个延时的逻辑都会受到影响。
针对以上问题，利用延时消息的特性投递到消息队列里，便是一个较好的解决方案，能统一计算延时时间，同时重试和死信机制确保消息不丢失。
具体场景的示例如下：
·微信红包发出后，生产端发送一条延时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();}
五、延时消息
延时消息通过生产者producer的 deliverAfter() 方法实现，代码示例如下：
String value = "message content";//需要指定延时的时长long delayTime = 10L;//通过调用 producer 的 deliverAfter 方法来实现定时消息MessageId msgId = producer.newMessage() .value(value.getBytes()) .deliverAfter(delayTime, TimeUnit.SECONDS) //单位可以自由选择 .send();
六、使用说明和限制
·使用定时或延迟消息时，建议与普通消息使用不同的 Topic 来管理，即定时与延迟消息发送到一个固定的 Topic，普通消息发送到另一个 Topic 中，方便后续的管理与维护，增加稳定性。
·使用定时和延时两种类型的消息时，请确保客户端的机器时钟和服务端的机器时钟（所有地域均为UTC+8 北京时间）保持一致，否则会有时差。
·定时和延时消息在精度上会有1秒左右的偏差。
·定时和延时消息不支持 batch 模式（批量发送），batch 模式会引起消息堆积，保险起见，请在创建 producer 的时候把 enableBatch 参数设为 false。
·定时和延时消息的消费模式仅支持使用 Shared 模式进行消费，否则会失去定时或延时效果（Key-shared 也不支持）。
·关于定时和延时消息的时间范围，最大均为10天。如果生产延迟消息超过 10 天，可能会导致客户端阻塞或反复重连。
·使用定时消息时，设置的时刻在当前时刻以后才会有定时效果，否则消息将被立即发送给消费者。
·设定定时时间后，TTL 的时间依旧会从发送消息的时间点开始算消息的最长保留时间；例如定时到2天后发送，消息最长保留（TTL）如果设置为1天的话，则消息在1天后会被删除，这个时候要确保 TTL 的时间要大于延时的时间，即 TTL 设置成大于等于2天，否则 TTL 到期时，消息会被删除。延时消息同理。
·普通类型 Topic 支持收发定时/延时消息，调用 使用方式 中的 API 即可发送定时/延时消息。