4

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

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

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

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

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

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

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

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

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

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

4

2 回答 2

3

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

  • 您可以添加可能无限数量的消费者而不会受到限制。
  • 当您添加另一个依赖应用程序时，它不需要更改您的 KCL 来推送到它，新应用程序将只监视 SQS 队列。
  • 当问题发生时，您可以获得监控队列的能力。
  • 需要设置更多移动部件，但是一旦Streams -> SNS -> SQS管道安装到位，它基本上是防弹的。

只是我的2美分。

于 2017-01-27T20:32:01.507 回答
0

如今，具有订阅功能的 AWS AppSync GraphQL API 可能是为此类应用程序提供支持的最简单方法，并且移动部件的数量最少。

每当您的一个应用程序启动时，它会使用Amplify框架或AppSync SDK连接到您的 AppSync GraphQL API并订阅其感兴趣的更新。然后，每当应用程序通过您的 GraphQL API 更新表中的信息时，您的所有其他应用程序将被通知更改，以及相关的更改数据。

AppSync 与开箱即用的 DynamoDB 完美集成，允许您在 GraphQL 旁边生成具有适当索引的 DynamoDB 表，或者根据您的选择从现有 DynamoDB 表生成 GraphQL。Amplify 甚至可以帮助您使用其GraphQL 转换器自动生成更高级别的 AppSync GraphQL API，其中包含关联的 DynamoDB 表、索引、实体关系，以及更像弹性搜索的搜索功能。

于 2019-06-27T15:59:12.540 回答