我一直在寻找任何答案，但是我读到的所有内容都是关于并发lambda执行和Node中的async关键字语法的，但是我找不到有关lambda实例执行的信息。
产生的原因是我正在开会，有人提到lambda实例（即由AWS托管的包含我的代码的临时容器）一次只能执行一个请求。这意味着，如果我收到5个请求（为简单起见，让我们说一个已经很暖和的实例），它们将全部在一个单独的实例中运行，即在5个单独的容器中运行。
对我而言，香蕉的事情是，这破坏了异步编程的多年发展。从2009年开始，node.js考虑到I / o的普及而进行了编程，因为对于无聊的Milled CRUD应用程序运行，您的大部分请求时间都花在了等待外部DB调用上。编写异步代码允许单个执行线程似乎执行多个同时请求。尽管node并未发明它，但我认为可以说它已经普及并在过去十年中一直是后端技术开发的巨大推动力。许多语言已经添加了一些功能，以使异步编程更加容易（回调/任务/承诺/未来或您想要调用的任何对象），并且Web服务器已从基于事件循环（节点，vertx，kestrel等）的位置转移到每个请求的单个线程之外过去一年的模型。
无论如何，在历史课程中，我的意思是，如果我听到的是正确的，那么使用lambdas进行开发会将大部分内容抛诸脑后。如果lambda运行时永远不会通过我正在运行的实例发送多个请求，那么以异步方式进行编程只会浪费资源。举例来说，我在说C＃，而我的lambda是用于检索小部件的。然后，此代码var response = await db.GetWidgets()实际上是效率低下的，因为它将当前线程上下文推送到堆栈上，这样它就可以在等待该调用返回时允许其他代码执行。由于在原始请求完成之前不会调用任何其他请求，因此以同步方式进行编程更有意义，除了可以进行并行调用的地方。
这是正确的吗？
如果是这样的话，我真的感到震惊，这里不再赘述。在过去的几年中，异步编程发生了范式转换，这完全改变了这一点。
TL; DR：lambda是否真的每个实例一次只允许一个请求执行？如果这样的话，这将结束服务器开发向异步代码的重大转变。
答案 0 :(得分：0)
是的，您是正确的-即使您的Lambda异步执行某些工作，Lambda也会旋转多个容器来处理并发请求（我已经根据自己的经验确认了这一点，并且许多其他人也观察到了相同的行为-参见{{ 3}}。对于每个受支持的运行时（C＃，Node.js等）都是如此。
这意味着您的Lambda函数中的异步代码不允许一个Lambda容器一次处理多个请求，如您所述。话虽如此，您仍然可以获得异步代码的所有其他好处，并且仍然可以通过例如一次异步地进行多个Web服务或数据库调用的方式潜在地提高Lambda的性能-因此Lambda的此属性 not < / em>使异步编程在平台上无效。
答案 1 :(得分：0)
您的问题是：
由于在原始请求完成之前不会调用其他任何请求，因此以同步方式进行编程更有意义，除非可以进行并行调用。
否，因为您不再需要像等待同步过程那样等待答案。您的触发器本身必须在调用后死亡，以便释放内存。一旦完成，lanba要么发送通知，要么触发新服务，或者由观察者查看结果值（可以通过同步lambda等待答案，但是由于lambda下的底层异步过程而导致结果不准确系统本身）。作为Android开发人员，您可以将其与意图和广播进行比较，并且是完全异步的。
这是一种设计解决方案的完全不同的方法，因为异步机制必须在工作流层本身上进行管理，而不再在应用程序的核心中进行管理，解决方案将成为触发微服务的通知程序/观察程序的集合不再是一千行代码的二进制文件。
每个lambda函数必须是一个单独的微服务。
再次处理繁重的流量，只要您的微服务很快结束，您就可以并行运行数百万个Lambda，这不会花费太多。 为了确保您的工作流不会丢失任何东西，您可以在解决方案中添加SQS（队列消息传递）。