mysql - Web 应用程序中的数据库连接

Question

以下是我们可以在 Web 应用程序环境中用于数据库连接的不同技术。

1. Application Context Database Connection: 所有请求只共享一个数据库连接。
2. Database Pooling:打开固定数量的数据库连接，并在所有请求之间共享连接。
3. 每个请求的新数据库连接:为每个请求打开一个连接。

这些技术的优点和缺点是什么？开发者应该使用哪一个？

Answer 1

选项 1. 在所有 Web 用户之间共享一个数据库连接必然会因某种原因而失败。一个长时间运行的查询和您的整个服务器将逐渐停止。对于 99.9% 的现代应用程序，甚至是非基于 Web 的应用程序，这是一个硬性的“不”。

选项 2. 连接池。可能是 Web 应用程序连接到数据库的第二常用技术。首先，如果数据库和池/web 应用程序在同一台机器上，好处将非常有限。然而，池和 Web 应用程序可以轻松地存在于同一硬件上。这里的好处是数据库连接的打开成本很高，并且在较小程度上，保持打开的成本很高。打开连接需要 CPU 使用率和内存分配。连接池可以保持几十个连接几乎可以立即“附加”到。内存已经分配好，大部分设置工作也已经完成，因此连接和断开连接池的速度相对较快。池通常始终保持一定数量的连接打开，并随着流量的增加而增加。在流量过大时，池通常会对连接请求进行排队，这样数据库就不会过载。排在队列后面的用户会遇到延迟，但系统会流失，并且通常不太可能由于内存不足而停止运行和磁盘交换。

选项 3。每个请求的新数据库连接。在轻度到中度使用的系统上，这不是一个糟糕的选择，而且通常很容易在以后升级到 pooler。但是请记住，每个数据库连接(每个页面加载)都需要打开和关闭数据库连接，这涉及 CPU 和内存分配。实际上，如果您的页面加载速度很快，您的用户群很小且稳定，并且您的流量相当稳定，那么它就可以正常工作。许多 DEV、CAT 和 QA 环境是直接连接的，没有 pooler。缺点是#1，绝对没有办法控制与数据库的连接。如果查询挂起，您可能有数百个连接突然终止您的数据库，有时需要重新启动或重新启动数据库才能纠正这种情况。

例如:您在网站主页上编写了 1 个错误查询，导致它需要 3 秒而不是 0.3 秒来运行。最终，您的网站在任何时候都有 1-2 个页面在运行，现在可能会增加到 10-20 个。现在这 10-20 个页面 = 10-20 个数据库连接不断打开和关闭，平均打开 10-20 个。这个问题会蔓延，使用越来越多的内存，直到达到连接限制(或者更糟，用完所有内存和现在交换的所有内容)。此时，一切都停止了。

请记住，连接会占用数据库和应用程序服务器/池的资源。当您的数据库分页到磁盘时，大多数情况下，在不重置某些内容的情况下进行优雅恢复的所有希望都破灭了——显然它可能会发生，但如果没有代码修复，您通常会重新启动以给自己更多时间，直到问题不可避免地出现再次发生，希望到那时，您已经找到了错误的查询或错误的配置并修复了它。

选项 2 为您提供了最多的选择。这通常不是管理上的难题，但如果你在一台机器上运行它，好处是有限的。如果您至少有 2 台机器(应用服务器和数据库服务器)，这是一个简单的解决方案，通常可以防止许多系统过载。