Amazon SQS 是处理分析日志数据到数据库的好工具吗？

Question

我们有一些 nodejs 服务器，需要将每个请求的详细信息和负载记录到 SQL Server 以进行报告和其他业务分析。

服务器之间的请求数量和需求相似性让我想通过集中式日志服务来解决这个问题。我的第一直觉是使用像 Amazon SQS 这样的东西，让它直接充当 SQL Server 的缓冲区，或者构建一个小型日志服务器，该服务器将由 SQS 引导数据库调用。

这听起来像是 SQS 的一个很好的用途，还是我错过了一个广泛使用的工具来完成这项任务？

Answer 1

解决方案实际上取决于您使用的数据量，因为每项服务都有限制。仅举几例：

SQS

• 首先，由于您正在处理日志，因此您不希望重复。考虑到这一点，您需要FIFO (first in first out) queue。
• SQS 本身并不真正调用任何东西。您在这里要做的是设置队列，然后通过 AWS JS 开发工具包进行调用以提交消息。然后，当您在回调中取回消息时，获取消息 ID 并将该数据传递给调用的 Lambda 函数（您也可以在 NodeJS 中编写这些函数），该函数将您需要的信息存储在数据库中。
• 也就是说，重要的是要知道 SQS 队列中的消息有大小限制：

最小消息大小为 1 个字节（1 个字符）。最大值是 262,144 字节 (256 KB)。

要发送大于 256 KB 的消息，您可以使用 Amazon SQS Java 的扩展客户端库。该库允许您发送 包含对消息负载的引用的 Amazon SQS 消息 亚马逊 S3。最大负载大小为 2 GB。

CloudWatch 日志

（不要与高级云手表服务本身混淆，后者更多的是发送指标）

• 这里的想法是您将事件数据提交到 CloudWatch 日志
• 这里也有限制：

事件大小：256 KB（最大）。此限制无法更改

• 与 SQS 不同，CloudWatch 日志可以自动将日志数据传递给 Lambda，然后可以将其写入您的 SQL 服务器。 AWS 文档explain how to set that up。

S3

只需设置一个存储桶并让您的服务器将数据写入其中。这里的好处是，由于 S3 用于存储大文件，您真的不必担心前面提到的大小限制。 S3 存储桶也有可以trigger lambda functions 的事件。然后您就可以愉快地继续发送徽标数据了。

如果您的日志数据足够大，您可以扩展到 AWS Batch 之类的东西，它可以为您提供一个可用于处理日志数据的容器集群。最后，您还可以获得数据备份。如果您的数据库出现故障，您已经将日志数据存储在 S3 中，并且可以组合一个脚本来加载所有内容。您还可以使用Lifecycle Policies 将旧数据迁移到成本更低的存储中，或者直接将其全部删除。