为什么我应该关闭或保持 Redis 连接打开? [英] Why should I close or keep Redis connections open?

问题描述

我在一个 PHP 项目中使用 Redis.我使用 phpredis 作为客户端.有时，在执行较长的 CLI 脚本期间，我会遇到 PHP 分段错误.

I'm using Redis in a PHP project. I use phpredis as a client. Sometimes, during long CLI-scripts, I experience PHP segmentation faults.

我之前经历过连接超时时 phpredis 出现问题.由于我的 Redis 配置被配置为在 300 秒后自动关闭空闲连接，我猜这会导致分段错误.

I've experienced before that phpredis has problems when the connection times out. As my Redis config is configured to automatically close idle connections after 300 seconds, I guess that causes the segmentation fault.

为了能够选择是增加连接超时还是默认为0(即永不超时")，我想知道可能的优缺点是什么?

In order to be able to choose whether to increase the connection timeout or default it to 0 (which means "never timeout"), I would like to know what the possible advantages and disadvantages are?

为什么我永远不应该关闭连接?
为什么我要确保连接不会保持打开状态?

谢谢

推荐答案

通常，打开连接是一项代价高昂的操作，因此现代最佳实践是保持连接打开.另一方面，打开的连接需要资源(来自数据库)来管理，因此保持大量空闲连接打开也可能有问题.这种权衡通常通过使用连接池来解决.

Generally, opening a connection is an expensive operation so modern best practices are to keep them open. On the other hand, open connections requires resources (from the database) to manage so keeping a lot of idle connections open can also be problematic. This trade off is usually resolved via the use of connection pools.

也就是说，更有趣的是为什么 PHP 会出现段错误.显然，超时是由长时间运行的命令(在您的情况下为 CLI 脚本)导致的，该命令阻止了 Redis(主要是单个线程)从参与 PHP 应用程序的连接.虽然这是众所周知的 Redis 行为，但我希望 PHP(在客户端库中没有重新连接功能的事件)不会如此悲惨.

That said, what's more interesting is why does PHP segfault. The timeout is, evidently, caused by a long running command (CLI script in your case) that blocks Redis (which is mostly single threaded) from attending to the PHP app's connections. While this is a well-known Redis behavior, I would expect PHP (event without featuring reconnect at the client library) not to s**t its pants so miserably.

这篇关于为什么我应该关闭或保持 Redis 连接打开?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！