目前，我正在使用ec2 + sqs + s3实施大数据解决方案。我的想法是，我在s3上托管了一个庞大的文件数据库。使用我的应用程序的客户端将提交规则匹配，尝试匹配s3上可用的所有相关文件，然后评估条件语句，将输出返回给用户，显示哪些文件与条件匹配。
我显然无法直接对我的s3文件执行规则匹配，因为没有阻止ec2实例中的重复作业，我会调整以进行规则匹配。也没有分工。
我的初始解决方案是整合Amazon SQS：当客户端发出请求时，S3中的所有文件都将加载到队列中。这将允许我的ec2实例执行分工+没有重复，因为SQS负责这一点。
但是，使用上述解决方案，我会在每次发出客户端请求时将所有文件加载到SQS队列中，这显然是浪费（更不用说暴涨的SQS成本）。理想情况下，我希望有一个持久化队列，一次加载我的所有文件（并且当更多文件添加到我的s3时，还会加载更多文件）。
有关如何创建大数据队列结构的任何想法？我应该抛弃SQS，还是应该通过在处理完消息之后删除消息并保持保留的SQS实例始终运行来使SQS像持久队列一样运行？
感谢。
答案 0 :(得分：2)
假设您的规则匹配事物基于文件元数据而不是文件内容，您可以将有关文件的元数据存储在实际数据库中，如Amazon DynamoDB，并进行匹配。
永久存储您的数据＆＃34;在SQS中（不删除邮件）不是一个好主意 - 邮件的大小有限，如果您不删除邮件，它们将再次可用于后续请求 - 您将获得更多重复这条路。此外，SQS 不提供任何有关重复的保证 - 事实上它至少是一次＆＃34;至少一次＆＃34;递送
如果您正在运行与文件内容匹配的规则（可能除了元数据之外），这听起来就像您真正想要的那样，那么您可以使用Amazon SimpleWorkflow 和Flow API构建在顶部它：
SWF有两个主要组件 - 工作流（维护状态）和活动（执行工作的无状态代码）。对于您的情况，工作流将每个请求分成许多工作块并将活动提交给SWF服务。您的活动工作人员将在许多EC2实例上运行 - 他们的工作是基本上接收作业（即：在指定的S3文件子集上运行您的规则匹配代码）并返回结果。然后，工作流将合并活动结果并对结果执行某些操作。
Flow framework recipies文档提供了一些很好的示例，说明了您需要同时执行多项活动并整合结果所需的代码模式。
因此，总而言之，要专门回答您的问题：放弃SQS并使用专为此类使用模式设计的SWF。