AWS 中具有持久存储的滑动延迟和计时器解决方案

Question

我需要创建一个滑动计时器

• 当ID为A的事件发生时，创建一条ID为60分钟的记录
• 当 ID 发生 B 类事件时，更新 ID 记录以重置 60 分钟计时器
• 当记录过期时，发送到SQS队列

我需要能够

• 根据具有 UUID 的输入，创建 60 分钟的计时器
• 根据已接收到的 UUID 的输入，更新 60 分钟的计时器
• 能够在不丢失计时器的情况下重放关闭和恢复计算基础设施
• 计时器尽可能快地归零

我的问题是如何可靠地做到这一点。应用程序服务器可能会或可能不会在给定时间对归零计时器进行操作，但需要能够在它们重新上线时进行操作。所有计时器（或时间信息）必须存储在应用程序服务器外部。给定时间最多可以有 10k 个计时器。

我可以使用 Redis/Elasticache TTL 来解决这个问题

• 应用程序服务器将对事件类型 A 做出反应，并在 60 分钟内创建/更新内存中的记录
• 应用程序服务器将订阅键事件到期并在到期时发送到 SQS 队列

但是，数据存储不可靠，因此对底层 Elasticache 的更新会丢失所有记录，或者应用程序服务器的可用性可能会导致错过计时器。此外，redis 服务器不会在 60 分钟后可靠地发出事件；它可以根据 Redis 服务器正在处理的缓存上的项目数量进行延迟。

正在寻找几个选项来可靠地存储表中的计时器并对其做出反应，但陷入停滞

• DynamoDB TTL 可以持续数天，并且不如 Redis TTL 可靠
• DynamoDB 和 cronjob lambda（每分钟）作为替代，但主要问题是 lambda 需要

  scan

  表来获取所有记录并确定是否发生到期时间（lastUpdatedTime > 60 分钟）。不能使用

  query

  ，因为 ID 可能包含多个计时器，并且 PK/SK 无法更改值（无需删除旧密钥并添加新密钥）
• SQS 最长延迟时间为 15 分钟

Answer 1

如果您选择 Redis 路线，您可以使用 MemoryDB，它是具有持久数据存储的 Redis。

DynamoDB TTL 不会为您提供所需的粒度。

EventBridge 计划可能是实现它的好方法，您可以使用 DynamoDB 作为前端数据存储，并使用流和 Lambda 在事件 B 发生时更新计划。

使用 EventBridge 时间表，您可以获得 1 分钟的事件粒度。您可以将事件推送到应用程序可以从中提取的 SQS 队列中。当您的应用程序恢复时，您将在队列中看到所有错过的事件。

唯一需要注意的是，如果事件清零并进入队列，然后事件 B 也在您的应用程序关闭时尝试更新它，您可能会获得该事件两次。