结论：redis-py-cluster 不支持连接池复用，其本身不提供 ConnectionPool 机制，也不支持复用底层 Redis 实例的连接池；每个节点需独立配置 ConnectionPool，不可共享同一实例。
redis-py-cluster 不支持连接池复用，这是根本限制
直接说结论：redis-py-cluster 库本身不提供连接池（ConnectionPool）机制，也**不支持复用底层 Redis 实例的连接池**。它的设计是每个 RedisCluster 实例内部维护一组独立的 Redis 客户端（每个 slot 节点一个），而这些客户端默认使用的是无池的短连接行为（实际依赖 redis-py 的默认 ConnectionPool，但无法由用户统一配置或共享）。
常见误操作是试图传入自定义 connection_pool 参数——它会被忽略，因为 RedisCluster.__init__ 根本不接收该参数。
如何让每个节点实际走连接池（有限复用）
虽然不能全局复用一个池，但可以让每个节点上的 Redis 客户端各自使用自己的连接池。关键在于：必须通过 init_slot_cache=False + 手动构造带池的 Redis 实例，并传给 startup_nodes 中的 host/port 配置。
-
redis-py-cluster从 v2.1.0+ 开始，允许在startup_nodes中为每个节点指定redis_client和redis_kwargs - 你需要为每个启动节点预创建一个带池的
redis.Redis实例（注意不是redis.ConnectionPool单独传） -
RedisCluster会绕过自身初始化逻辑，直接使用你提供的客户端对象
示例：
立即学习“Python免费学习笔记（深入）”；
from redis import Redis, ConnectionPool
from rediscluster import RedisCluster
<h1>为每个节点单独建池（不能共用同一个 pool 实例！）</h1><p>node1_pool = ConnectionPool(host='127.0.0.1', port=7000, max_connections=20)
node2_pool = ConnectionPool(host='127.0.0.1', port=7001, max_connections=20)</p><h1>构造带池的 Redis 客户端</h1><p>node1_client = Redis(connection_pool=node1_pool)
node2_client = Redis(connection_pool=node2_pool)</p><h1>启动节点列表需包含 client 字段</h1><p>startup_nodes = [
{"host": "127.0.0.1", "port": "7000", "redis_client": node1_client},
{"host": "127.0.0.1", "port": "7001", "redis_client": node2_client},
]</p><p>rc = RedisCluster(startup_nodes=startup_nodes, init_slot_cache=False)
为什么不能共享同一个 ConnectionPool？
同一个 ConnectionPool 实例绑定固定 host:port，而集群中不同节点地址不同。若强行复用，会导致连接错发到错误节点（例如向 7000 的池里发请求，却期望连上 7001），引发 ConnectionError 或数据错乱。
此外，redis-py-cluster 内部做重定向（MOVED/ASK）时，会动态切换节点，此时必须能按目标地址获取对应池——它没有实现跨地址池路由能力。
- 每个节点必须配独立
ConnectionPool（或至少独立Redis实例） - 池的
max_connections建议设为 10–30，过高反而因锁竞争降低吞吐 - 务必设置
socket_timeout和socket_connect_timeout，避免阻塞卡死
替代方案：用 redis-py + cluster-aware 逻辑手动分片
如果对连接复用要求极高（比如单进程要支撑数千 QPS 且节点数少），更可控的做法是放弃 redis-py-cluster，改用原生 redis.Redis + 自行哈希选节点：
- 用
hash_ring或crc16.crc16计算 key 对应 slot - 查本地 slot → node 映射表（可通过
CLUSTER SLOTS初始化一次） - 用预创建的、按 node 分组的
Redis实例（每个 node 一个带池客户端）执行命令
这样你能完全控制池生命周期、健康检查、故障转移策略——但代价是失去 redis-py-cluster 封装的自动重试和重定向逻辑。
真正容易被忽略的点是：很多人以为调大 max_connections 就能提升并发，其实当节点数多于 8 个、且业务 key 分布不均时，大量连接会空闲在少数热节点上，冷节点池利用率极低——这时不如用连接数适中+合理超时+快速失败重试更稳。
