大型消息 Amazon SQS答案

【问题标题】：Large message Amazon SQS大型消息 Amazon SQS
【发布时间】：2015-09-09 23:27:24
【问题描述】：

我有一个使用 JMS 发送大约几兆字节的文件的应用程序。是否可以使用 Amazon SQS 作为此应用程序的 JMS 提供程序，如 here 所述？

这里的问题是 SQS 消息的最大大小是 256K。解决此问题的一种方法是将每个文件分解为多个 256K 的消息。但是，如果我这样做，是否会让多个生产者同时发送文件会破坏架构，因为来自不同生产者的消息会混淆？

【问题讨论】：

【解决方案1】：

在这种情况下，您不能将原始消息与 SQS 一起使用，您必须使用引用原始消息的新消息。引用可以是 S3 对象或本地或 AWS 内部的自定义位置。 S3 选项可能涉及的工作量最少，成本效率最高（构建和运行）。

如果您考虑使用 S3 选项，可以使用 AWS Lambdas 将消息放入 SQS。

附带说明，这里考虑的原始消息似乎是自包含的。重新访问消息的内容可能是个好主意，您可能会找到修剪它的方法并仅发送会导致更小的有效负载的位置。

【讨论】：

【解决方案2】：

如果一切都在同一个区域 - 延迟和数据传输成本非常低。将一个项目放入 S3 并让对象在 SQS 中发送应该只是让您的解决方案处理任何大小的数据，并减轻您在项目的可伸缩性和每个项目的大小方面的工作。

虽然我说数据传输成本很低，但您可能仍会在 S3 中产生数据存储成本；您可以使用 S3 生命周期规则将其删除。

@D.Luffy 提到了一个重要且令人兴奋的 lambda 解决方案 - 您可以继续在 S3 中添加项目 - 启用 S3 通知，将其发送到队列并处理队列项目（将其传输到另一个 ec2 实例等） ) - 让解决方案着火并忘记一些东西。

请不要犹豫，将 S3 与 SQS 结合使用

【讨论】：

谢谢。事实证明，S3 具有最终一致性，这意味着写入其中的内容可能不会立即可供读取。在这种情况下，我必须在发送 SQS 消息之前确保读取可用，对吗？
这也不是什么大问题 - 有一个非常简单的解决方法。我还没有看到一致性延迟不超过几秒钟。如果您对此非常担心 - 您可以放心地将 5 分钟作为等待时间，然后再从队列中读取。您可以在创建新的 SQS 队列时指定 DELIVERY DELAY。这意味着 - 延迟第一次传递添加到队列中的所有消息的时间量。所以在这里指定为 5 分钟。