AWS Lambda异步调库不等Promise解析的可行性与RDS Proxy连接优化

在数据库查询Promise未完成解析时直接结束Lambda运行的操作不具备可靠可行性。Lambda运行时一旦判定所有事件回调执行完毕，会立刻回收执行环境占用的所有计算、网络资源，挂起的异步数据库请求会随连接被硬切断直接丢失，根本无法保证送达RDS Proxy并完成存储过程执行。
如果确实需要“发送请求后不等待结果”的体验，不要靠切断Lambda运行时实现，可将更新请求写入同区域SQS队列，由独立的消费Lambda拉取队列消息执行数据库写入，既不阻塞主流程，也能保证请求不丢失。

• 方案一触发连接终止错误的核心原因是时序错位：在client.query()发起异步调用、请求尚未从客户端内存发送至RDS Proxy完成传输校验时，同步执行client.end()主动切断了连接管道，导致未完成的查询被强制中断，直接抛出连接终止类异常。
• 方案二产生过多冗余连接的核心原因是缺少连接复用逻辑：每次Lambda冷启动都在处理器内部新建Client实例、建立全新的到RDS Proxy的TCP连接，且未做空闲连接的合理释放，短时间内会产生大量短生命周期的无效连接请求，挤占RDS Proxy的连接配额。

针对RDS Proxy场景，可通过两层逻辑实现目标：

1. 应用层连接复用
   把数据库Client实例的声明从Lambda处理器函数内部移到全局作用域，利用Lambda执行环境的冻结核复用特性，不要每次请求都重新初始化Client、重新执行connect()建连。全局作用域的Client实例在执行环境未被回收前会一直存在，后续同执行环境的请求可直接复用已建立的TCP连接，无需反复完成TCP三次握手、数据库鉴权流程。
   RDS Proxy本身自带连接池汇聚能力，核心作用就是承接Lambda场景下的短调用、避免后端数据库被大量短连接打垮，但应用层基础的Client复用可以大幅降低RDS Proxy侧的冗余连接请求量，减少连接管理开销，避免触发连接数阈值。示例代码结构如下：

   // 移到全局作用域，而非处理器函数内部
   let client;
   exports.handler = async (event) => {
     // 仅在Lambda冷启动时初始化一次Client、建立连接
     if (!client) {
       client = new Client("rds-proxy连接串")
       await client.connect()
     }
     // 复用现有连接直接发起存储过程调用
     client.query('call 目标存储过程')
   }
   

2. 历史连接的正确终止
   不要在查询发起的瞬间就调用client.end()，需等查询请求的Promise状态落定（成功/失败均可）后再执行连接关闭操作，即可避免时序错位导致的连接终止错误。如果需要终止RDS Proxy侧长期残留的空闲无效连接，可直接在RDS Proxy的连接管理界面选中对应连接执行终止操作，无需在客户端侧反复重连测试。

内容的提问来源于stack exchange，提问作者Siddharth Choudhary