MySQL与Redis数据库连接池介绍（图示+源码+代码演示）

说实话，在经常使用数据库连接池之后，你才能真正感受到它所提供的便利。
我以前在电子商务项目中遇到过这种情况。
当系统并发量增加时，没有连接池，CPU直接增加到9 0%以上。
说白了，每次请求都要重新建立连接，消耗的资源太多。

有趣的是，如果你考虑一下 TCP 三向握手过程，仅此一项就可能需要数十毫秒。
我已经在低并发场景下测试过，如果一条SQL命令没有连接到池中，从连接建立到执行完成可能需要1 00ms左右。
添加池后怎么样？由于连接是提前创建的，因此可以直接获取请求，总体花费的时间可以减少一半以上。
我记得在那个测试用例中，使用连接池的系统响应时间从 4 秒下降到 2 秒。
在商业中，这种差异可以决定用户是否会流失。

但需要注意的是，越多越好。
我见过一些初学者将连接池设置得太大，结果系统一重启数据库就崩溃了。
我记得有一篇技术文章说，连接池的大小最好由CPU核心数决定，公式为（核心数2 ）+1 当然，这不是绝对的真理，要看具体的业务场景。
例如，在您的示例中，具有 9 个连接的 4 核 i7 可能有点浪费，除非您的业务逻辑特别复杂。

说到实现，CDBConn 类的设计非常清晰。
m_pDBPool指向它所属的池，Init函数负责建立连接。
GetDBConn和RelDBConn的空闲队列机制。
我已经使用过类似方案的Redis客户端，效果确实不错。
但请注意，测试前数据库地址必须正确。
我朋友因为配置没改，编译后就报错，而且花了很长时间。

redis_pool部分也很有趣。
我记得Redis连接池实现比较简单，因为Redis本身单连接速度非常快。
你的测试数据很有说服力。
它从 1 8 2 ms 下降到 2 1 ms。
这个提升简直就是一个数量级的变化。
不过，这也与Redis本身的内存运行优势有关，不能完全归因于连接池。
但总的来说，使用Redis连接池还是可以显着提升性能的，特别是在高并发读的场景下。

但说实话，在我上论坛的近1 0年里，我看到太多人让连接池变得“多余”。
有些系统本身就是短连接模式，比如消息队列，增加硬连接池会增加复杂度。
因此，是否使用取决于您的具体业务场景。
你的视频技巧相当全面，从TCP/IP到各种中间件，学习它们确实有帮助。
但请记住，技术是为人服务的，不要仅仅为了使用而使用它。

php进阶到架构之swoole系列教程（三）mysql连接池-

哈，你问的是mysql连接池。
这确实是实现共同货币需要克服的主要问题。

我参加的挑战是2 02 2 年的一个电子商务行动项目。
当时，系统正在运行。
预计达到每秒 1 ,5 00+。
结果，刚测试完，数据库就崩溃了。
缓慢的查询会填满日志文件。
尽管我们使用的是高性能读写集群，但我们后来调查发现，每个请求都会创建一个新的数据库连接，并立即达到 4 00 个并发连接的上限。

解决方案是创建连接池。
一个特定的函数是在程序启动时。
它首先与数据库建立 3 00 个长连接，并将这些连接放入池中。
然后当他询问时，从这个池中获取直接连接，并在使用后将其添加回来。
这样，即使有1 000个并发连接，实际占用的数据库连接也只有3 00个。
数据库压力小了很多，性能确实提升了很多。

我对如何实现 swoole 的看法是使用 swoole 的数据库池。
例如 swoole_db::getInstance() 返回连接数；可以配置超时时间等。
关键是内存必须足够大，以便这3 00个连接在程序启动时建立并始终打开。
因为连接被复用；一旦在编码时将其删除，就无法将其恢复。
您必须在事务或查询完成后集中精力将其放回。

但是链接桥接并不是万能的。
2 02 3 年在上海某购物中心做项目时；遇到不合理的连接池模式。
本来是想提高性能，但是连接池太小了。
当发送并发请求时；仍有队列等待连接。
最终，效果还不如直接打开长连接那么差。
所以怎么设置取决于你的业务情况和数据库负载，需要迭代测试。

无论如何，你只需要弄清楚。
首先，了解原理；练习配置；测试更多场景。