如何在 AWS Lambda 上使用 MongoDB 连接池？

AWS Lambda: An event-driven, serverless computing service by Amazon Web Services. Users upload code and set up event triggers; AWS Lambda takes care of administrative tasks like provisioning servers, scaling, etc. It supports various runtimes like Node.js, Python, Java, and Go and can be directly triggered by AWS services like S3, DynamoDB, Kinesis, SNS, etc. In the example, the AWS API gateway is used to trigger Lambda functions.
Connection Pool: Opening and closing a database connection is expensive. A connection pool is a cache of database connections kept alive. Applications can borrow a connection from the pool, perform operations, and return it. The size of the connection pool is configurable in most MongoDB drivers. A larger pool size can handle more parallel requests, but it needs to be carefully chosen considering the application load and concurrency.
MongoDB Connection Pools in AWS Lambda:
- Java Driver: By declaring a sgMongoClient variable outside the handler function, connection pooling is achieved. The variables remain initialized across calls as long as the same container is reused.
- Node.js Driver: Declaring the connection variable in global scope also enables connection pooling. The callbackWaitsForEmptyEventLoop property in Lambda's context object needs to be set to false for connection pooling to work.
AWS Lambda Connection Pool Analysis and Observations:
- Performance Test: Tests were run for Java and Node.js Lambda functions with and without connection pools using the AWS API gateway as a trigger. The average response time with a connection pool was significantly lower as it reuses connections instead of opening and closing them for each operation.
- Cold Start Time: It is the time taken for the AWS Lambda function to initialize when receiving the first request. It varies based on the programming language. When using the API gateway as a trigger, cold start time must be considered as the API gateway response will error out if the function isn't initialized in the given time range. Firing an initialization request before actual invocation or having a retry on the client side can address cold start time issues.
- Inactivity: AWS Lambda hosting containers are stopped when inactive for a while (7 to 20 minutes). If Lambda functions are not used frequently, keeping them alive by firing heartbeat requests or adding retries on the client side is necessary.
- Concurrent Invocation: When Lambda functions are invoked concurrently, many containers are used. The connection pool size needs to be optimal to handle concurrent requests. Once containers are stopped, connections are released based on timeout from the MongoDB server.
Conclusion: Lambda functions are stateless and asynchronous. Using a database connection pool adds state but is beneficial when containers are reused, saving time. Connection pooling with AWS EC2 is easier to manage as a single instance can track the connection pool state. AWS Lambda is designed to work better without connecting to a database engine directly.