Amazon dynamodb 以下哪种设计模式（带或不带SQS）应用于处理AWS中的峰值数据量？

我正在进行AWS研究，在网上遇到了这个似乎有争议的问题，我想知道在这里发布是否可以获得更多的信息：

一家公司正在为一个受欢迎的电视节目建立一个投票系统，观众先观看节目，然后参观 该节目的网站为他们最喜欢的演员投票。预计在事故发生后的短时间内 展会已结束该网站将接待数百万访客。访问者将首先使用他们的 然后提交他们的投票。投票完成后，页面将显示 投票总数。该公司需要建立这样的网站，可以处理快速涌入的交通，同时 保持良好的性能，但也希望将成本降至最低。哪种设计模式 下面他们应该使用什么

A.使用CloudFront和一个弹性负载平衡器在 自动缩放web服务器集，web服务器将首先可以 使用Amazon服务登录以验证用户身份，然后处理 用户投票并将结果存储到多AZ关系数据库中 服务实例

B.使用CloudFront和S3的静态网站托管功能 调用Amazon登录服务的Javascript SDK 验证用户身份，使用IAM角色获得对DynamoDB的权限 表来存储用户投票

C.使用CloudFront和一个弹性负载平衡器在 自动缩放web服务器集，web服务器将首先调用 使用Amazon服务登录以验证用户和web服务器 将处理用户投票并将结果存储到DynamoDB表中 使用EC2实例的IAM角色获得对DynamoDB的权限 桌子

D.使用CloudFront和一个弹性负载平衡器在 自动缩放web服务器集，web服务器将首先调用 登录。通过Amazon服务对用户进行身份验证，web服务器 win处理用户投票并将结果存储到SQS队列中 使用EC2实例的IAM角色获得对SQS的权限 队列然后，一组应用服务器将从中检索项目 队列并将结果存储到DynamoDB表中

原来的问题来自 这是一个很有争议的问题

我的想法是限制AWS服务的数量，使成本降到最低。这里不包括RDS，因为有三个选项指向DynamoDB（我不是云大师，这是我的直觉判断）。S3只适用于静态网站，所以不包括B

在C&D之间，我选择C作为1。它不需要使用额外成本的SQS；2.SQS是否能够以预期的IOPS/吞吐量处理卷？我不知道，但C&D都使用DynamoDB，我认为这是一个很好的解决方案，D没有指出应用服务器（即EC2实例）访问DynamoDB所需的权限。所以这里不包括D

我有什么遗漏吗

没有为这个问题提供标准和权威的答案

---

非常感谢您的讨论。

这是一个非常固执己见的问题

这是解决问题的一种方法

设计注意事项

短时间内的大量请求

a。我们必须能够自动缩放

b。写流量应该分散，这样我们就不必提供大量的dynamodb容量

c。读取不需要执行数据库连接和计数操作，这样我们就不必提供大量的RAM和dynamodb容量

假设

最终投票的一致性是好的

书写应该是非常一致的。（如果投票是不可变的（一旦完成就不能更改），则可以使用sqs，否则引入sqs会给系统带来很多复杂性。如下所述）

架构

组件

使用CloudFront和S3的静态网站托管功能为网站供电。（这样可以水平伸缩。）（PS这种方法称为客户端渲染，有很多缺点，比如seo，在选择这种方法之前要做研究，如果你需要服务器端渲染，在aws elb后面有另一台服务器，它调用其他服务并创建页面。这两种方法的优点和缺点是什么，对于剩下的答案，我假设你是d正在进行服务器端渲染。）

网站调用您的服务来呈现页面

您的服务部署在ec2上，并启用了自动缩放功能

所有读取都是从弹性缓存（它们部署在主从配置中，因此没有单点故障）

所有写入都一致地进入dynamodb。（如果在任何给定时间点都无法确定系统的确切状态，则大多数服务需要获得一致的状态来决定下一个状态，如果在这两者之间有sqs队列，则需要获得一致的状态。但这也意味着我们需要为dynamodb支付更多的费用。为此，需要在dynamodb上启用自动缩放。）

由于负载的主要部分将被读取，所以将聚合保留在弹性缓存中。要更新弹性缓存，可以向dynamodb change streams订阅lambda函数

或有事项

您应该有一个计划来填充弹性缓存，以防它发生故障，并且您必须重新水化该状态

---

以下是您选择的缺点

选项A的缺点：

这将需要巨大的rsu，因为您将聚合结果

选项B的缺点：

这将需要巨大的rsu，因为您将聚合结果

考虑到您存储和检索数据的方式可能会随着时间的推移而变化，从前端直接调用dynamodb可能不是一个好主意