Beego 不内置 Redis Sentinel 支持，需用 go-redis v9 的 NewFailoverClient 显式配置 MasterName、SentinelAddrs 等参数；初始化须在 main() 或 init() 中完成，避免 controller 内新建客户端；务必设置 Dial/Read/Write 超时并启用日志埋点。
Beego 本身不内置 Redis Sentinel 支持，所有客户端连接逻辑由你控制；直接硬编码 redis-cli 或用 go-redis 手动连哨兵，大概率会连错、切不及时、甚至卡死——这不是配置问题，是架构层缺失自动发现机制。
go-redis v9 连接 Sentinel 的正确姿势
go-redis 是当前 Beego 项目中最常用、也最适配哨兵的 Redis 客户端（v8/v9 已原生支持 Sentinel），但必须避开几个典型误用：
- 错误写法：
redis.NewClient(&redis.Options{Addr: "127.0.0.1:26379"})—— 这只连单个哨兵，不是集群，无法获取主节点地址 - 正确方式：用
redis.NewFailoverClient，显式传入哨兵列表和主节点名
client := redis.NewFailoverClient(&redis.FailoverOptions{
MasterName: "mymaster", // 必须和 sentinel.conf 中 sentinel monitor 的名字一致
SentinelAddrs: []string{"192.168.10.30:26379", "192.168.10.31:26379", "192.168.10.32:26379"},
Password: "123456", // 主节点密码（非哨兵密码）
DB: 0,
})
-
MasterName不是随便起的，必须和sentinel monitor mymaster 192.168.10.30 6379 2中第一个参数完全一致 -
SentinelAddrs至少填 3 个哨兵地址，少于 3 个会导致客观下线判断失败（quorum 投票不足） - 哨兵进程默认不设密码，若强制加了 auth，请在每个
sentinel.conf中配requirepass，并在FailoverOptions中加SentinelPassword字段
Beego 启动时初始化 Redis 客户端的坑
Beego 的 app.Run() 之前是唯一可靠时机做全局客户端初始化；放在 controller 里 new client 是灾难性设计：
- 每次请求都新建
FailoverClient→ 大量 goroutine 泄漏 + 哨兵轮询风暴 - 没调
client.Close()→ 进程退出时连接不释放，下次启动可能端口占用或认证残留
推荐写法（放在 main.go 的 init() 或 main() 开头）：
var RedisClient *redis.Client
<p>func initRedis() {
client := redis.NewFailoverClient(&redis.FailoverOptions{
MasterName: "mymaster",
SentinelAddrs: []string{"192.168.10.30:26379", "192.168.10.31:26379", "192.168.10.32:26379"},
Password: "123456",
DB: 0,
MaxRetries: 3,
MinRetryBackoff: time.Millisecond <em> 8,
MaxRetryBackoff: time.Millisecond </em> 16,
})
if err := client.Ping(context.TODO()).Err(); err != nil {
panic("failed to connect to redis sentinel: " + err.Error())
}
RedisClient = client
}</p>然后在 main() 里调用 initRedis()，并在 os.Interrupt 信号捕获中加 RedisClient.Close()。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
故障转移期间的读写行为与超时设置
go-redis 的 FailoverClient 在主节点切换时不会阻塞写请求，但有两件事必须手动干预：
- 默认
read timeout和write timeout都是 0（无限等待），一旦哨兵正在选主、新主还没 ready，SET可能 hang 住 3–5 秒甚至更久 - 从节点默认可读，但
FailoverClient不自动 fallback 到 slave；如需读从，得显式用client.WithContext(ctx).ReadOnly().Get(...)
关键超时字段建议：
-
DialTimeout: time.Second * 3 -
ReadTimeout: time.Second * 2 -
WriteTimeout: time.Second * 2 -
PoolSize: 50（避免连接池耗尽，尤其高并发场景）
这些值不是拍脑袋定的：它们要略大于 sentinel failover-timeout（默认 180000ms），否则故障转移未完成时请求就超时返回错误，掩盖了真实可用性。
哨兵模式真正的复杂点不在配置，而在于「谁在什么时候、以什么节奏重试、重试失败后是否降级、降级是否影响数据一致性」——这些逻辑全压在客户端。Beego 没抽象这一层，所以你写的每一行 RedisClient.Get，背后都绑着哨兵发现、主节点心跳、连接复用、failover 状态机。别跳过日志埋点，至少在 Ping 和 Set 前后打上 redis.master.addr 标签，否则切主出问题时，你连自己连的是哪个节点都不知道。
