所以我们有一个运行Python烧瓶应用程序，利用Celery和AWS SQS来满足我们的异步任务需求。
我们最近面临的一个棘手问题是创建一个任务，以便在 x 天或 3 小时内运行。我们对这样的东西有几个需求。
现在，我们在数据库中创建带有时间戳的事件，这些时间戳存储应触发它们的时间。然后，我们利用芹菜节拍每秒运行一次计划任务，检查是否有任何事件要处理(基于触发器时间戳(，然后处理它们。但是，这是每秒查询数据库以查找我们认为可以以某种方式改进的事件。
我们研究了在芹菜 (http://docs.celeryproject.org/en/latest/userguide/calling.html( 中使用 eta 参数，该参数可让您安排任务在 x 时间内运行。但是，拥有大型 ETA 似乎是不好的做法，而且 AWS SQS 的可见性超时约为两个小时，因此超过此时间的任何时间都会导致冲突。
我现在挠头。在一个有这个工作，并且相当不错，因为事情已经与SNS，SQS等分开，以确保缩放容差。但是，每秒查询数据库以处理事件感觉不到写入。当然，Google/AWS提供了一种更简单的方法或服务来安排某些事件(发布/订阅(在未来的某个时间(x小时，分钟等(发生。
有什么想法吗？
您是否看过 AWS Step Functions，特别是 Wait State？您可以将几个 lambda 函数放在一起，第一个函数返回时间戳或等待进入等待状态的秒数，最后一个在等待返回后将消息添加到 SQS。
亚马逊的调度解决方案是使用CloudWatch来触发事件。这些事件可以是将消息放入 SQS/SNS 终端节点、触发 ECS 任务、运行 Lambda 等。很多人使用执行 Lambda 的技巧，然后执行其他操作来触发系统中的某些内容。例如，您可以触发一个 Lambda，将作业推送到 Redis 上，供 Celery 工作人员拾取。
创建 Cloudwatch 规则时，您可以指定"速率"(即每 5 分钟一次(或 CRON 语法中的任意时间。
因此，我对你的用例的建议是放弃在你的工作需要启动时(或一分钟前，取决于你的时间敏感度(运行的 cloudwatch 规则。然后，该规则将与您的应用程序交互以启动您的工作。您只需在 CloudWatch 触发时为资源付费。
您是否研究过Amazon Simple Notification Service？听起来它可以满足您的需求... https://aws.amazon.com/sns/
从该页面：
Amazon SNS 是一种完全托管的发布/订阅消息收发服务，可以轻松分离和扩展微服务、分布式系统和无服务器应用程序。借助 SNS，您可以使用主题将消息发布者与订阅者分离，一次将消息扇出到多个收件人，并消除应用程序中的轮询。SNS 支持多种订阅类型，允许您将消息直接推送到 Amazon Simple Queue Service (SQS( 队列、AWS Lambda 函数和 HTTP 终端节点。AWS 服务(如 Amazon EC2、Amazon S3 和 Amazon CloudWatch(可以将消息发布到您的 SNS 主题，以触发事件驱动的计算和工作流。SNS 与 SQS 合作，为构建容错且易于扩展的云应用程序提供强大的消息传递解决方案。
您可以使用apply_async开始作业，然后使用倒计时，例如：
xxx.apply_async(...， 倒计时=TTT(
不能保证作业在那个时间准确启动，具体取决于队列的繁忙程度，但这在您的用例中似乎不是问题。