问题标签 [amazon-dynamodb-dax]

我的 3 节点 DAX 集群出现以下错误：无法检索端点 Traceback（最后一次调用）：

我的设置： - 私有 Lambdas - Python 3.6 - amazon-dax-client - 配置设置 - 超时 300 毫秒，最大重试次数 5 - vpc 有 3 个子网 - DAX 集群有 3 个 r4.large 节点

这个错误间歇性地发生 - 大多数时间它仍然“有效”，但考虑到它发生的频率，它令人担忧。

我的服务使用带有 DAX 的 AWS dynamodb，在高负载下我的请求失败并出现此错误-

"error":"RequestCanceled：请求上下文取消，原因是：超出上下文截止日期

关于这个错误可以归因于什么的任何想法？

我想问的是，当我们向 DynamoDB DAX 集群添加更多节点时，它将跨节点分配数据，并且缓存容量将等于（节点数*节点容量）或更多节点仅用于可用性和负载分配容量作为单个节点的容量？

我们正在使用 DynamoDB 全局表，并计划在 DynamoDB 之上使用 DAX 来启用缓存。但我没有看到任何提及 DAX 失效将如何在多区域设置中发生。

例如，假设有 2 个集群，一个在 us-west-2 中，一个在 us-east-2 中。如果我们使用 DAX 客户端更新 us-east-2 中的某些内容，它的缓存将被更新，但是在将数据复制到 us-west-2 时，全局表是否也会更新 us-west-2 中的缓存？我在DynamoDB 文档中没有看到任何提及。

应用：

我有一个 Java 应用程序，其输入中有尖峰/突发，代表事件。每个事件总是有一个读取，一个决策（逻辑），然后基于该决策可能的写入（插入或更新）。大多数读取不会导致日常写入（插入/更新）。从理论上讲，这对于 DAX 和 DynamoDB 来说是一个很好的方案，具有按需计费/配置。

场景/问题：

当发生恰好由写入峰值组成的突发时，我们有时（但不总是）会看到通用 AmazonClientException 实例的峰值。异常有一个retry（即isRetry()），false根本原因是具有通用消息值/字符串的 InternalServerException 实例，其中包括有 500 响应的文本（没有额外的细节或清晰度）。

这些 DAX 异常及其堆栈跟踪确实无法深入了解其真正原因（例如，节流、调整大小之前的临时供应吞吐量异常、主机不可用等）。这似乎是来自 DAX 的意外响应行为，似乎是 DynamoDB On-Demand 调整大小对我来说（有关更多提示，请参阅下面的其他信息），但是当它们确实发生时，我仍然对这些原因的一些损失/不清楚针对这种情况。

附加信息：

• 我正在使用 Java DAX 客户端的最新可用实例。
• 在突发之外，读/写是连续成功的。这包括在受控测试用例中使用事件/数据创建慢速馈送时，这些馈送是在先前在突发中创建异常时捕获的。
• 使用 Provisioned（不是 On-Demand）时，我们看不到这些模糊的客户端异常。我们确实看到了来自 DAX 的吞吐量达到异常，正如对于相同的突发/峰值场景所预期的那样，并根据这些异常isRetry()（即true）使用成功的退避重试策略来识别我们可以/应该重试。

设想：

我们有一个流式 Java 应用程序，它通过 DAX 使用最新的 DAX 客户端实例对 DynamoDB 执行读/写请求。在执行简单的集成测试和性能测试时，我们会间歇性地看到没有可用端点的异常。

澄清一下，间歇性意味着一些请求会成功，然后一些请求会失败，只有在单个测试（集成或性能）中再次让请求再次成功。事实上，这些测试运行中的大多数将在没有看到此错误的情况下成功，但它确实偶尔会发生，如最后一句中所述。

DAX 和 DynamoDB 的开发实例是常设实例，这意味着运行这些测试不会重新构建/部署 DAX 或 DynamoDB 实例以实现全新的状态（它们在测试运行之间保持启动并运行）。

问题：

在使用 DAX 的小规模测试（例如集成/e2e 测试）或更大规模的测试（例如性能测试）中，有没有其他人看到过这种间歇性行为的类似模式？我知道这已经在人们无法连接到 DAX 的场景的其他票证上进行了讨论，但是我没有看到任何问题或场景可以识别此类间歇性行为。

我试图为现有的 Lambda 函数配置 DAX，该函数将数据读取和写入 DynamoDB。在引入 DAX 之前一切正常，之后，写入停止工作，写入的数据没有任何变化。

在调试时，我发现它们因以下异常而失败：

我目前已将我的 DAX 集群的项目缓存 TTL 设置为 0。我找不到任何关于无限超时的好的文档。但这是否对应于无限超时？

我正在为我的应用程序使用 aws lamda 函数和 dynamodb 和 api 网关

并使用 Apache bench 进行负载测试，我已经成功运行了测试

1000 个请求和 100 个并发

这是结果

测试#1

并发级别：100

测试时间：0.920 秒

完成请求：1000

失败的请求：0

每秒请求数：1086.60 [#/sec]（平均）

每个请求的时间：92.030 [ms]（平均值）

每个请求的时间：0.920 [ms]（平均值，所有并发请求）

之后，我添加了 DAX（dynamodb 加速器）以将响应时间减少到预期的微秒

但我得到了相同的结果

测试#2

并发级别：100

测试时间：0.853 秒

完成请求：1000

失败的请求：0

每秒请求数：1172.12 [#/sec]（平均）

每个请求的时间：85.315 [ms]（平均）

每个请求的时间：0.853 [ms]（平均值，所有并发请求）

我们在生产中的应用程序经常中断，因为它无法承受负载。现在，api 是登录 api，这是非常关键的一个。在登录 api 中，我们有 3 个休息调用和 8 个 dynamodb 调用（6 个读取调用和 2 个写入调用 - 项目大小始终小于 1 kb，我们正在寻找最终的一致性）。微服务在嵌入式 tomcat(7) 上运行，我们使用的是 spring boot。正如我从 tomcat 文档中看到的那样，它默认有 200 个线程，而我的 1 个请求大约需要 800 毫秒才能完成。那么，您能帮我对 dynamodb RCU 和 WCU 进行什么配置吗？是否值得将 DAX 用于读取调用，以及将它与现有应用程序集成有多简单。我们有 2 个实例在微服务的生产环境中运行，出于某种原因，如果我们能找出什么配置应该是合适的，那么我们可以增加实例，我们应该为 RCU 和 WCU 增加多少？请指导。