我们目前正在Amazon的AWS上实现分布式Spring Boot微服务架构，其中我们使用SNS/SQS作为我们的消息传递系统:
事件由Spring Boot服务发布到使用Spring Cloud AWS的SNS FIFO主题。主题将事件移交给订阅主题的多个SQS队列，然后这些队列依次由不同的消费者服务(再次使用Spring Cloud AWS的Spring Boot)使用。
一切正常，但我们有时看到生产服务的延迟非常高。
我们的产品还没有发布(我们目前正在测试中)，这意味着我们在prod上的流量非常非常低，也就是说，每天只有几条消息。
不幸的是，在长时间不活动之后，我们看到消息传递到其订阅者之前的延迟非常高(通常长达6秒，但也可能高达60秒)。之后，随着消息传递时间降至100ms以下，发送到该主题的下一个消息的速度大大加快。
在AWS中打开SNS主题的登录显示，第一条消息的大部分延迟都花在了SNS部分，其中SNSdwellTime与我们在消息传递中看到的延迟大致相关。Spring Cloud AWS看起来不错。
这是预料之中的吗?有没有类似"冷启动"的东西?空闲SNS FIFO主题的时间(如使用AWS lambda时所见)?一旦我们增加负载并加热主题，这种延迟是否就会消失?还是我们在配置时遗漏了什么?
我们正在使用相当标准的SQS订阅，顺便说一句，没有订阅限制。Spring Boot服务运行在Fargate ECS集群上。
似乎AWS以某种方式停用了未使用的SNS主题。我们现在要做的是，我们发送一个"假人";每十分钟向主题发送Keep-Alive消息，这使我们的dwellTime保持在合理的低水平(<500ms)