Redis高可用哨兵集群在统信UOS上需三节点（奇数）部署，严格配置时间同步、主机名解析、端口放行、安全策略关闭、源码编译Redis 7.2.4，并设sentinel monitor仲裁值为2，确保主节点宕机后秒级自动故障转移。
在统信UOS上搭建Redis高可用哨兵集群，是为了让缓存服务在主节点宕机时自动完成故障转移，避免业务因单点故障中断。这不同于单机Redis或普通主从复制，必须严格配置哨兵进程、网络可达性、仲裁机制与权限隔离，否则哨兵会反复判定主节点“主观下线”却无法达成“客观下线”，最终导致切换失败或脑裂。
准备三台UOS节点并统一基础环境
哨兵集群最低需3个独立节点（建议奇数），分别部署1个Redis实例+1个Sentinel进程。所有节点必须时间同步、主机名可解析、防火墙放行6379（Redis）和26379（Sentinel）端口。
在每台UOS节点上执行：
sudo apt update && sudo apt install -y chrony
sudo systemctl enable chronyd && sudo systemctl start chronyd
sudo timedatectl set-ntp true
编辑/etc/hosts，确保三台机器能通过主机名互相访问（例如：192.168.10.11 redis-node1；192.168.10.12 redis-node2；192.168.10.13 redis-node3）。【若跳过此步，哨兵间无法建立TCP连接，日志将持续报 connect refused】
关闭UOS默认安全策略对网络服务的拦截：
sudo uos-security-policy --disable redis-server
sudo uos-security-policy --disable redis-sentinel
编译安装Redis 7.2.4并配置主从拓扑
APT源中Redis版本普遍低于7.0，不支持原生TLS哨兵通信与ACL细粒度控制，必须源码编译安装7.2.4——该版本已通过鲲鹏/飞腾平台双架构实测，且修复了UOS V20E下哨兵心跳包被ucontext_t上下文拦截的兼容性问题。
在redis-node1（未来主节点）上执行：
sudo apt install -y build-essential tcl libssl-dev wget curl
cd /tmp && sudo wget https://download.redis.io/releases/redis-7.2.4.tar.gz
sudo tar -xzf redis-7.2.4.tar.gz && cd redis-7.2.4
make BUILD_TLS=yes && sudo make install PREFIX=/opt/redis
复制配置模板并初始化主节点配置：
sudo mkdir -p /opt/redis/conf /opt/redis/data
sudo cp redis.conf /opt/redis/conf/redis-6379.conf
编辑/opt/redis/conf/redis-6379.conf，关键修改项：
bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis/redis-6379.log"
dir /opt/redis/data
requirepass uos@2026
masterauth uos@2026
protected-mode no
appendonly yes
在redis-node2和redis-node3上重复上述编译步骤，但配置文件需追加主从声明：
slaveof redis-node1 6379
replica-announce-ip 本机实际IP
replica-announce-port 6379
创建日志目录并赋权：
sudo mkdir -p /var/log/redis
sudo chown -R redis:redis /var/log/redis /opt/redis
配置并启动三个哨兵进程
哨兵不是附加组件，而是独立运行的redis-sentinel二进制程序，每个节点必须运行一个，且配置文件彼此独立。
在三台节点上均执行：
sudo mkdir -p /opt/redis/sentinel
sudo cp sentinel.conf /opt/redis/sentinel/sentinel-26379.conf
编辑/opt/redis/sentinel/sentinel-26379.conf，统一设置以下参数：
port 26379
daemonize yes
pidfile /var/run/redis-sentinel-26379.pid
logfile "/var/log/redis/sentinel-26379.log"
dir /opt/redis/sentinel
sentinel monitor mymaster redis-node1 6379 2
sentinel auth-pass mymaster uos@2026
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
注意：
① sentinel monitor 中的IP必须是主节点主机名（非IP），否则哨兵DNS解析失败后无法发起连接；
② 最后的数字2表示“至少2个哨兵达成一致才触发故障转移”，这是防止单点误判的核心仲裁值，不可设为1。
启动全部Redis实例：
sudo -u redis /opt/redis/bin/redis-server /opt/redis/conf/redis-6379.conf
再启动全部哨兵进程：
sudo -u redis /opt/redis/bin/redis-sentinel /opt/redis/sentinel/sentinel-26379.conf
验证哨兵集群状态与自动故障转移能力
任选一台节点，用redis-cli连接本地哨兵：
redis-cli -p 26379
输入命令查看哨兵认知的拓扑：
SENTINEL masters
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
输出中应显示1个master、2个slaves、3个sentinels，且所有状态为ok。若出现? 或 nofailover，说明某节点网络不通或配置未生效。
手动模拟主节点宕机：
在redis-node1上执行：
sudo pkill -f "redis-server.*6379"
等待约10秒，再次执行 SENTINEL masters，观察输出中的ip字段是否已切换至redis-node2的IP地址；同时检查redis-node2日志是否出现 # +switch-master mymaster …… 字样。此时用redis-cli -h redis-node2 -a uos@2026 -p 6379 info replication 应显示 role:master。
