无服务器数据库连接池

Question

我正在尝试在 aws 上构建一个 100% 无服务器的应用程序（现在减去数据库），我遇到的是数据库是瓶颈。我的应用程序可以很好地扩展，但我的数据库可以容纳的连接数是有限的，并且在某些时候，我的 lambda 会遇到这个限制。我可以在我的 lambdas 中的处理程序之外进行连接池，以便每个 lambda 容器而不是每个调用都有一个数据库连接，虽然这确实增加了我达到连接限制之前的并发调用数量，但限制仍然存在。

我有两个问题。1. serverless aurora 是否通过自动伸缩来增加实例数量来满足更多连接的需求来解决这个问题。2. 这个问题还有其他解决方案吗？

另外，从其他对无服务器感兴趣的开发人员那里，我是否正在尝试做一些不值得做的事情？我喜欢无服务器框架的部署是多么容易，但是在像 Kubernetes 这样的东西中使用微服务更好吗？

Answer 1

我相信这个问题有两种可能的解决方案：

第一个也是最简单的选项是利用“lambda 热状态”，这是 Lambda 为后续调用重用执行上下文时的概念。根据AWS的建议

Lambda 函数代码中的任何声明（在处理程序代码之外，请参阅编程模型）都保持初始化状态，从而在再次调用函数时提供额外的优化。例如，如果您的 Lambda 函数建立了数据库连接，则在后续调用中将使用原始连接，而不是重新建立连接。我们建议在您的代码中添加逻辑，以在创建连接之前检查连接是否存在。

基本上，虽然 lambda 函数是热门阶段，但它“可能/应该”重用打开的连接。

以下限制：

• 您只重用单个 lambda 类型的连接，因此如果您始终调用 5 个 lambda 函数，您仍然会使用 5 个连接
• 当 lambda 调用（包括并行执行）激增时，此方法的效果会降低，因为 lambda 将在新的执行上下文中针对大多数请求执行

第二种选择是使用连接池，连接池是已建立的数据库连接的数组，以便将来需要对数据库发出请求时可以重用这些连接。

虽然第二个选项提供了更一致的解决方案，但它需要更多的基础设施。

• 您将需要为池运行一个单独的实例，如果您想正确执行操作，可能至少需要两个实例和一个负载均衡器（除非使用容器）。

虽然为连接池提供这么多额外的基础设施可能会让人难以承受，但根据项目的规模、您现有的基础设施（可能您已经在使用容器）和成本效益，它仍然可能是一个有效的选择