MassTransit 8结合Amazon SQS/SNS定时消息发送技术问询

你的定时消息发送代码如下：

public Task Consume(ConsumeContext<RequestReceivedEvent> context)
{
    var uri = context.ReceiveContext.InputAddress;

    var scheduledTime = DateTime.UtcNow.AddHours(12);

    return context.ScheduleSend(uri, scheduledTime, new DelayedMessage());
}

针对你提出的技术疑问，解答如下：

• 定时发送消息的最大延迟间隔
  Amazon SQS原生延迟队列的最大延迟限制为15分钟（900秒），但MassTransit结合SQS/SNS使用时，会自动适配长延迟场景：

  • 当延迟时长≤15分钟时，直接使用SQS原生延迟队列能力
  • 当延迟时长>15分钟时，会通过SNS+CloudWatch Events实现定时触发，此时理论上无硬性最大延迟限制，可支持数小时、数天甚至更久的延迟需求

• 延迟信息存储位置
  延迟信息不会存储在MassTransit应用的内存中，而是依赖AWS的服务端存储：

  • 短延迟（≤15分钟）：消息直接存放在目标SQS队列中，由SQS服务器端控制投递时间
  • 长延迟（>15分钟）：消息先发送到SNS，同时在CloudWatch Events中创建定时触发规则，延迟信息存储在CloudWatch Events和SNS服务中

• 容器停机重启后的定时任务保留
  因为所有延迟相关的信息都存储在AWS的SQS/SNS/CloudWatch服务端，而非容器内的MassTransit进程内存中，所以即使Windows Docker容器停机重启，之前设置的定时发送任务依然有效，到了指定时间消息会正常投递到目标队列，MassTransit重启后可正常消费这些消息

内容的提问来源于stack exchange，提问作者JohnyMotorhead