ThinkPHPRedis哨兵模式怎么部署连接代码-ThinkPHP-PHP中文网

thinkphp 6/8 连接 redis 哨兵必须启用 phpredis 扩展并配置 sentinel 模式，仅靠 env('redis.host') 填数组无效；需在 cache.php 中严格设置 host（哨兵地址）、port（哨兵端口）、sentinel=>true、service（哨兵服务名）及 timeout，且 service 名须与 sentinel.conf 中定义完全一致。

thinkphpredis哨兵模式怎么部署连接代码

ThinkPHP 6/8 连接 Redis 哨兵（Sentinel）必须用 php redis 扩展，不能靠 `env('redis.host')` 填数组

TP 默认的 redis 缓存驱动只支持单节点或哨兵「发现」，但不支持自动故障转移——它不会调用 sentinelGetMasterAddrByName，也不会在主节点宕机后重连新主。直接在 config/cache.php 的 host 字段写成 ['127.0.0.1:26379', '127.0.0.1:26380'] 是无效的，TP 会把它当多个单节点轮询，连接时直接报 Connection refused 或静默 fallback 到 file。

真正能用哨兵的唯一路径是：启用 phpredis 扩展 + 在配置中显式声明 sentinel 模式 + 指定 service 名。

确保 PHP 已启用 redis 扩展（不是 predis），运行 php -m | grep redis 验证
config/cache.php 中的 redis store 必须包含以下字段，缺一不可：
'type' => 'redis'
'host' => '127.0.0.1'（哨兵地址，非 Redis 地址）
'port' => 26379（任意一个哨兵端口）
'sentinel' => true（关键开关）
'service' => 'mymaster'（你在哨兵配置里定义的 master name）
'timeout' => 2.5（建议设小值，避免卡住）
不要填 password 字段来连哨兵——如果哨兵本身设了密码，需在 sentinel.conf 中配 requirepass，并在 PHP 的 redis 扩展中通过 ini_set('redis.sentinel.auth', 'xxx') 全局设置（非 TP 配置项）

哨兵配置必须匹配，`service` 名大小写敏感且不能含下划线

TP 的 phpredis 驱动底层调用的是 Redis::connect() 的哨兵模式，它会向哨兵发 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster。如果返回空或格式错误，就会连不上，现象是缓存始终走 file，日志里却没报错。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

检查点：

登录任意哨兵节点执行 redis-cli -p 26379 sentinel masters，确认输出里有 name:mymaster（和你配置的 service 完全一致）
确认该 master 的 ip 和 port 是可被 PHP 进程访问的（比如 Docker 网络隔离、云服务器安全组放行）
如果哨兵监控的是带密码的 Redis 主从，确保 sentinel.conf 里有 sentinel auth-pass mymaster your_redis_password，否则即使发现主节点，后续连上去也会因认证失败被拒绝
TP 不支持在一个配置里同时指定多个哨兵地址做高可用——它只连第一个 host:port，靠哨兵集群内部通信保障发现能力

连接成功后，`Cache::store('redis')->handler()` 返回的是 phpredis 实例，不是 Predis

这意味着你能直接调用原生方法，比如 $redis->set('key', 'val')，但不能用 Predis 特有的语法（如 multi() 返回 Predis\Transaction\Transaction）。更重要的是：所有命令都由当前连接的 Redis 节点执行，TP 不做读写分离——写操作一定打到主节点，读操作默认也打主节点（除非你自己用 slaveof no one 或 readonly 指令切从）。

验证是否真走哨兵：在哨兵日志（sentinel.log）里搜 +switch-master，然后触发一次主节点宕机，看 TP 应用是否自动恢复写入（而不是卡死或降级）
如果要用从节点读，必须手动获取 handler 后调用 $redis->setOption(Redis::OPT_READ_TIMEOUT, 1) 和 $redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_NONE)，再执行 $redis->slaveof('127.0.0.1', 6380) ——但这属于非常规操作，且每次请求都要重连，不推荐
注意 select 参数仍生效：它作用于最终连上的 Redis 实例，不是哨兵。所以 'select' => 1 表示连上主/从后执行 SELECT 1

常见静默失败场景：哨兵连得上，Redis 连不上

最隐蔽的问题是：TP 成功从哨兵拿到了主节点地址（如 10.0.1.5:6379），但 PHP 进程根本访问不到那个 IP。此时 TP 不报错，只是后续所有 Cache::get() 都返回 null，且日志里只有首次连接时的一条 RedisException: Connection refused，之后复用连接池就完全静默。

排查顺序：先用 php -r "new Redis(); $r->connect('10.0.1.5', 6379); echo 'ok';" 手动测试能否直连目标 Redis 地址
确认 PHP 进程网络环境（FPM 容器是否和 Redis 在同一子网？宿主机防火墙是否拦截？）
不要依赖 timeout 参数掩盖问题：'timeout' => 0 会导致请求卡死；'timeout' => 0.5 更利于暴露真实连通性
如果 Redis 主节点启用了 ACL，而哨兵配置里没设 sentinel auth-pass，则 TP 能发现主节点，但连上去执行 SET 时会静默失败（无异常，值不写入）——此时需检查 Redis 日志里的 Authentication required