【发布时间】：2021-01-13 14:52:41
【问题描述】：
需求：需要批量消费来自sqs队列的消息。处理时需要对数据进行一系列操作。消息频率在一段时间内可能会很高，因此应用程序应该能够通过相应的缩放来处理它。我们正在开发更长期的应用程序，一旦开发完成，应该不会有任何重大的开发变化。
项目基于基于下拉向导的框架。
选项：
- Lambda - 排除此选项，因为在 lambda 的情况下，sqs 中的大量消息会导致更多失败（最终出现在 dlq 中）。此外，我需要对数据进行不止一项操作，其中 lambda 只适合对其进行一项操作。
- AWS SQS SDK - 需要为此写下线程逻辑（用于轮询和消息处理）
- AWS 提供了基于 jms 的 sqs sdk (amazon-sqs-java-messaging-lib) - 似乎非常适合我的用例。因为它将处理轮询和并发逻辑。但问题是这个 jar 的最新版本是从 2019 年 4 月开始的。已经快 2 年了，这个库仍然没有更新。还有许多未解决的问题。
我担心 aws 会停用这个库，而且我的项目应该以这样的方式构建，所以将来不应该有重大的开发变化，比如依赖关系的变化。
有人可以告诉我我是否可以选择这个库，还是坚持使用香草 aws sqs sdk 更好？如果还有其他选择，请务必提及。
----------------------------------- - - - - -更新 - - - - - - - - - - - - - - - - - - - - --------------------- 感谢建议使用 lambda 或 step 通过增加并发限制的数量来解决 1000 tps 的重负载。 我还对我的项目用例进行了更多分析，并决定使用普通 AWS SQS sdk 与 SQS 交互的容器化 APP。
做出此决定的原因：
SQS -> My_APP -> 另一个应用程序
- 正如您所看到的流程，我需要从 My_APP 与另一个可以支持某些 tps 的应用程序进行交互。如果我可以控制轮询逻辑，我可以解决这个问题。
- 还有 My_APP - 它不是一个简单的过程。这里将发生超过 1 个进程。 （转换，一些映射，...）
- 我发布此问题的原因是为了获取有关 amazon-sqs-java-messaging-lib 库的一些更新。我最终没有继续走这条路，因为我不确定将来在这个库上是否支持 aws。
【问题讨论】：
-
为什么 lambda 会导致失败？您的“大量消息”有多少？
-
高峰期，预计 1200 tps 左右。
-
没那么多。你可以让 lambda 来做。您可以要求支持将默认的并发限制从 1000 增加到 2000。
-
感谢您指出。我忘了再补充一点——这里的处理就像对数据的一系列操作。而 lambda 最适合仅处理一项操作。我也负担不起每个操作的 1 个 lambda - 这可能会导致高成本。这就是我正在使用 aws 提供的 sdk 研究 ec2 中的一些容器应用程序的原因。
标签： java amazon-web-services jms amazon-sqs