Redis连接池不能直接用Connection，因频繁创建/销毁TCP连接会导致性能下降和“Too many open files”错误；必须用ConnectionPool复用连接，且全局唯一、显式传入redis.Redis，配好max_connections、health_check_interval和decode_responses等关键参数。
Redis连接池为什么不能直接用Connection？
直接每次操作都新建redis.Connection对象，会频繁创建/销毁TCP连接，既慢又容易触发系统文件描述符耗尽。Redis官方推荐始终复用连接，而redis.ConnectionPool就是为此设计的——它管理一组可复用的连接，按需分配、自动回收。
常见错误现象：ConnectionError: Error 24 connecting to localhost:6379. Too many open files.，本质是没走连接池，程序每发一次命令就开一个新socket。
- 必须显式创建
ConnectionPool实例，并传给redis.Redis构造函数的connection_pool参数，而不是host/port - 全局只应有一个
ConnectionPool实例（通常设为模块级变量），多个Redis客户端共享它 - 不要在函数内反复创建
ConnectionPool，否则等于没池化
如何配置max_connections和retry_on_timeout？
max_connections不是“最大并发请求数”，而是连接池里最多允许存在的空闲+活跃连接总数。设太小会导致请求阻塞在get_connection()；设太大可能压垮Redis或本地系统资源。
典型配置场景：Web应用单机QPS约500，平均每个请求用1个连接、持续200ms，则理论需要约100个连接缓冲。但实际建议从max_connections=50起步，结合监控调整。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
max_connections=50适合中小流量服务；高并发服务可设为200~500，但需同步检查Redis的maxclients配置（默认10000） -
retry_on_timeout=True让连接池在遇到TimeoutError时自动重试一次，避免因网络抖动导致的瞬时失败 - 务必设置
socket_connect_timeout和socket_timeout（单位秒），否则超时可能长达数分钟
连接池初始化时哪些参数容易被忽略？
很多人只配host/port，结果在生产环境遇到认证失败、编码错乱或连接复用异常。
-
password必须显式传入，即使Redis配置了requirepass，漏写会导致NOAUTH Authentication required错误 -
decode_responses=True让返回值自动从bytes转为str，否则所有GET结果都是b"xxx"，后续字符串操作极易出错 -
health_check_interval=30（单位秒）开启定期心跳检测，防止连接池中残留已断开的“僵尸连接” - 使用SSL连接时，必须传
ssl=True和ssl_cert_reqs=None（或对应证书路径），否则会报Connection closed by server
多线程/异步环境下连接池还安全吗？
redis-py的ConnectionPool本身是线程安全的，内部用threading.Lock保护连接获取逻辑。但要注意：它不兼容asyncio，在aioredis或redis-py 4.0+ 的Redis.from_url(..., decode_responses=True)异步模式下，必须用aioredis.ConnectionPool替代。
- Flask/Django等同步框架中，直接复用同一个
ConnectionPool实例没问题 - 若混用同步+异步调用（比如Celery任务里调同步Redis，Web请求走异步），必须分开维护两套连接池
- 连接池对象不可序列化，别试图把它存进
celery.task的args里传参，会报PicklingError
连接池不是“开了就行”的开关，max_connections、health_check_interval、decode_responses这三个参数一旦配错，问题往往延迟暴露——可能上线一周后才在高峰时段突然大量超时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
