amazon-dynamodb - DynamoDB 流是这个用例的正确选择吗？

Question

我有一个 DynamoDB 表，其中包含将由许多应用程序读取的键值对。在启动时，每个应用程序将读取整个表并将其缓存在内存中。

我试图解决的问题是，如果 DynamoDB 表中的一个或多个项目已被修改，则让应用程序更新其缓存。

DynamoDB 流最初似乎是解决问题的正确方法。我已经按照 AWS 的建议使用 Kinesis Client Library (KCL) 实现了使用者。然而，在实现它时，我遇到了一些问题，让我相信自己走错了路。具体来说:

当我使用 KCL 创建一个新的使用者时，它会创建一个新的 DynamoDB 表来处理租约和检查点，这样当应用程序重新启动时，KCL 知道哪些记录已被使用，哪些尚未被使用。这不是我解决这个问题所需要的。在应用程序离线时创建的任何流记录都是无关紧要的，因为在应用程序启动时会读取整个表。

同一应用程序的多个实例同时运行。他们每个人都需要收到表更新的通知。为了在 KCL 中实现它，我需要为每个应用程序分配一个唯一的应用程序名称。否则，他们将共享租用表，并且只有其中一个应用程序会收到通知。每个应用程序实例一个表似乎不正确。此外，我还需要一些东西来删除未使用的表。

我也使用低级 API 来实现它。当只有一个分片时，这很好用。然而，我的实现不像 KCL 那样处理重新分片，所以它太脆弱了。对于我试图解决的简单问题，必须实现重新分片的处理似乎是错误的。

我开始考虑其他解决方案，例如:

实现在更新表时触发的 lambda 函数。该函数向 SNS 主题发送通知。消费者在该主题上创建 SQS 订阅并通过该订阅获得通知。这个解决方案有太多我喜欢的移动部件。

使应用程序定期重新读取整个表并自行确定是否进行了更改。这个解决方案感觉有点原始，但似乎是最简单的。

到目前为止，我考虑的所有解决方案都有相当大的缺点。我错过了什么？

Answer 1

这取决于您的 KCL 如何推送到依赖的应用程序，但是
我相信 SQS 路径是正确的选择。

您可以添加大概无限数量的消费者而不会受到限制。

当您添加另一个依赖应用程序时，它不需要更改您的 KCL 来推送它，新应用程序将只监视 SQS 队列。

当问题发生时，您可以获得监控队列的能力。

更多事件部件需要设置，但一旦您拥有 Streams -> SNS -> SQS管道就位，它基本上是防弹的。

只是我的 2 美分。