我知道AWS已经允许SQS作为Lambdas的事件源映射之一。我很高兴现在这是可能的，因为那时我不必每隔几秒钟就从队列中轮询一次cron作业。然而，似乎batchSize的最大可能值被限制为10。根据我的理解，batchSize是单个Lambda调用将从队列接收的消息数。
这听起来对我来说可能是个问题，因为在我的情况下，我可能一次在队列中有几十万条消息。这些消息不需要任何繁重的处理；它们只需要被解析并作为记录保存到数据库中。这很简单。
如果batchSize每次检索仅限于10条消息，我预见到我可能会遇到一些问题：
-
实际上可能需要很长时间才能完成队列上的消息处理。
-
每次检索10条消息不仅速度慢，而且由于消息处理起来非常简单，在一次Lambda调用中只处理10条消息听起来有点浪费，因为考虑到处理消息所需操作的简单性，我敢肯定它在一次兰姆达调用中至少可以处理几千条消息。
-
每次检索只有10条消息也可能意味着我需要对数据库进行更多的写操作，因为这些消息中的每一条都需要作为记录插入数据库。
在这种情况下，我的担忧有效吗？如果是这样的话，我还能对SQS和Lambdas做些什么来克服这些担忧吗？
您关于限制为10的假设是正确的。
如果有更多的消息可用，Lambda将启动更多的实例并行运行。请参见缩放和处理。这意味着，如果有1000条消息可用，Lambda可能会启动100个并发执行，以快速处理所有消息。
lambda函数处理完一个批次的10条消息后，将继续处理其他批次。由于lambda以100毫秒为间隔计费，因此浪费的时间最少。
至于数据库写入，您可以在将消息插入队列之前对其进行预处理。
在这种情况下，您需要让lambda函数从队列中获取消息并进行处理，而不是通过SQS触发lambda。可能有一个云监视事件，它可以根据您的用例为您触发lambda
请注意，SQS一次最多只能发送10条消息，但您可以编写代码以提高效率。
其中一个非常有效的包装是挤压
在这种情况下，您可以让lambda函数运行15分钟(最长时间(，并让它处理尽可能多的消息。当您设计这类应用程序时，幂等性是关键，所以若在本次运行中未处理消息，它将在下一次运行中处理。
使用这种方法的缺点是，您需要根据预期的消息数量手动缩放lambda。
您说得对，较大的批量大小似乎适合您的用例。
截至2020年底，如果您以秒为单位指定批处理窗口，则可以指定最多10000条消息的批处理大小。
因此，有了这个新选项，您现在可以将lambda配置为等待，并在每次调用时接收更大的批。