AWS Lambda容器销毁事件 [英] AWS Lambda Container destroy event

问题描述

何时释放lambda中的连接和清理资源.在普通的Node JS应用程序中，我们确实使用了钩子

When to release connections and cleanup resources in lambda. In normal Node JS application we do use the hook

process.on('exit', (code) => {
    console.log(`About to exit with code: ${code}`);
});

但是，这在AWS Lambda上不起作用.导致Mysql连接进入睡眠模式.我们没有足够的资源来进行这种活动的连接.没有AWS文档指定实现此目的的方法.

However this doesn't work on AWS Lambda. Resulting the Mysql connection in sleep mode. We don't have enough resource for such active connections. None of the AWS documentation specify a way to achieve this.

如何接收AWS Lambda容器的停止事件?

How to receive stop event of AWS Lambda container ?

推荐答案

简短的答案是，没有此类事件可以知道容器何时停止.

The short answer is that there is no such event to know when the container is stopped.

中等答案:在与AWS的某人交谈后，我现在相信您应该在模块级别确定数据库连接的范围，以便只要容器存在就可以重用它们.当您的容器被销毁时，连接将被销毁.

The medium answer: after speaking with someone at AWS about this I now believe you should scope database connections at the module level so they are reused as long as the container exists. When your container is destroyed the connection will be destroyed at that point.

原始答案:

此问题涉及AWS Lambda函数要考虑的一些相当复杂的问题，主要是因为有可能考虑连接池或数据库的长期连接.首先，Node.js中的Lambda函数作为具有此签名的导出的Node.js函数执行(您可能知道):

This question touches on some rather complicated issues to consider with AWS Lambda functions, mainly because of the possibility of considering connection pooling or long-lived connections to your database. To start with, Lambda functions in Node.js execute as a single, exported Node.js function with this signature (as you probably know):

exports.handler = (event, context, callback) => {
    // TODO implement
    callback(null, 'Hello from Lambda');
};

处理数据库连接的最干净，最简单的方法是在每个函数调用中创建和销毁它们.在这种情况下，将在函数的开头创建数据库连接，并在调用最终回调之前销毁数据库连接.像这样:

The cleanest and simplest way to handle database connections is to create and destroy them with every single function call. In this scenario, a database connection would be created at the beginning of your function and destroyed before your final callback is called. Something like this:

const mysql = require('mysql');

exports.handler = (event, context, callback) => {
  let connection = mysql.createConnection({
    host     : 'localhost',
    user     : 'me',
    password : 'secret',
    database : 'my_db'
  });

  connection.connect();

  connection.query('SELECT 1 + 1 AS solution', (error, results, fields) => {
    if (error) {
      connection.end();
      callback(error);
    }
    else {
      let retval = results[0].solution;
      connection.end();
      console.log('The solution is: ', retval);
      callback(null, retval);
    }
  });
};

注意:我尚未测试该代码.我只是提供一个示例进行讨论.

NOTE: I haven't tested that code. I'm just providing an example for discussion.

我还看到了像这样的对话将连接放置在主要功能主体之外的可能性:

I've also seen conversations like this one discussing the possibility of placing your connection outside the main function body:

const mysql = require('mysql');

let connection = mysql.createConnection({
  host     : 'localhost',
  user     : 'me',
  password : 'secret',
  database : 'my_db'
});

connection.connect();

exports.handler = (event, context, callback) => {
  // NOTE: should check if the connection is open first here
  connection.query('SELECT 1 + 1 AS solution', (error, results, fields) => {
    if (error) {
      callback(error);
    }
    else {
      let retval = results[0].solution;
      console.log('The solution is: ', retval);
      callback(null, retval);
    }
  });
};

这里的理论是这样的:因为在第一次调用函数之后，AWS Lambda会尝试重用现有容器，所以下一个函数调用将已经打开数据库连接.上面的示例可能应该在使用之前检查打开的连接的存在，但是您明白了.

The theory here is this: because AWS Lambda will try to reuse an existing container after the first call to your function, the next function call will already have a database connection open. The example above should probably check the existence of an open connection before using it, but you get the idea.

当然的问题是，这会使您的连接无限期地打开.我不喜欢这种方法，但是根据您的具体情况，这可能会起作用.您也可以在该方案中引入连接池.但是无论如何，在这种情况下，您没有任何事件可以彻底销毁连接或池.承载您的函数的容器进程本身将被杀死.因此，您必须依靠数据库从某个时刻终止连接.

The problem of course is that this leaves your connection open indefinitely. I'm not a fan of this approach but depending on your specific circumstances this might work. You could also introduce a connection pool into that scenario. But regardless, you have no event in this case to cleanly destroy a connection or pool. The container process hosting your function would itself be killed. So you'd have to rely on your database killing the connection from it's end at some point.

在某些细节上我可能是错的，但我相信从高层次上讲，这就是您要查看的内容.希望有帮助！

I could be wrong about some of those details, but I believe at a high level that is what you're looking at. Hope that helps!

这篇关于AWS Lambda容器销毁事件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！