我的应用程序正在使用lambda函数（1）将数据导入到第三台数据库服务器。有时（1）会引发错误，而我使用SQS来存储从（1）引发的消息。我使用lambda函数（2）读取SQS中的所有消息，并通过撤回（1）重新导入。 （2）每当SQS收到消息时都会触发。
完整错误流：Lambda（1）=> SQS => Lambda（2）=> Lambda（1）。
问题是，如果维护数据库服务器，它将无限循环，直到再次激活数据库服务器为止。
我的解决方案是，创建一个lambda函数（3），就像执行标志一样，检查数据库服务器状态。它会在SQS收到新消息时运行，重复运行直到DB服务器再次活动。这次调用了Lambda（2）。
我希望此Lambda（3）是一个单线程（单线程？），来自SQS的所有请求都在一个线程中。
=>使用此解决方案，如果DB服务器关闭，系统仅需要重试一个线程。
新流程：Lambda（1）=> SQS =>单线程Lambda（3）=> Lambda（2）=> Lambda（1）
我的问题是：
答案 0 :(得分：0)
可以通过使用限制和CloudWatch计划的事件触发器来实现。
您可以将CloudWatch计划的事件设置为定期运行lambda函数3（负责DB状态检查的事件）。我不确定单线程的含义，但我想您的意思是，该函数最多只能同时运行一个实例。这很容易，因为CloudWatch计划的事件将根据您指定的 x-时间仅运行一次该功能。
上述函数（3）一旦检测到数据库不正常，就可以对从SQS（2）读取消息的lambda函数设置并发限制，并将其限制为0，这样就无法执行lambda函数（2）完全没有。
当功能（3）检测到数据库正常时，它将从功能（2）中删除此并发限制。
因此lambda函数（3）的代码可能看起来像这样
if db_is_not_healthy:
lambda.put_function_concurrency(
FunctionName=function_2,
ReservedConcurrentExecutions=0
)
else:
lambda.delete_function_concurrency(
FunctionName=function_2
)
您如何精确地设置lambda健康检查，何时启动它们，何时停止它们，对数据库执行ping操作的频率取决于您的特定用例以及您愿意为此支付多少费用。
例如，只有在数据库有一些错误之后，您才可以对数据库进行ping操作。一旦lambda函数（1）收到错误响应，它便可以启用运行状况检查-lambda（3）通过对其进行节流，并且一旦lambda（3）决定DB再次运行状况良好，它就可以限制自身，以便仅执行此运行状况检查数据库出现问题时。
这绝对不是最优雅的解决方案，但经过一些调整后它应该可以工作。