企业官网建设流程全解析

目录

一.环境准备

二.搭建Redis 主从复制

2.1Redis安装 部署

2.2Master节点配置

2.3Slave节点配置

2.4验证主从效果

三、Redis哨兵模式

3.1配置哨兵模式（所有节点操作）

3.2启动哨兵模式

3.3查看哨兵信息

3.4故障模拟测试

四.Redis 群集模式

4.1创建集群配置文件（每台机器两个实例）

4.2在另外两台机器上重复步骤3

4.3启动所有Redis实例（三台机器）

4.4组建集群（在一台机器上执行即可）

4.5验证集群状态

4.6测试数据写入

五.故障测试

六.redis说明

6.1 为什么选择该架构

①业务需求分析

②架构选型对比

③选择本方案的核心原因

6.2拓扑关系简图

6.3节点角色说明

七.总结

1. 环境准备与主从复制

2. 哨兵模式实现高可用

3. Redis Cluster 集群部署

4. 架构优势与特点

5. 关键注意事项

一.环境准备

• Master节点：192.168.10.110
• Slave1节点：192.168.10.111
• Slave2节点：192.168.10.112

系统配置：

systemctl stop firewalld setenforce 0

二.搭建Redis 主从复制

2.1Redis安装 部署

# 安装依赖 yum install -y gcc gcc-c++ make 解压安装包 tar zxvf redis-5.0.7.tar.gz -C /opt/ 编译安装 cd /opt/redis-5.0.7/ make make PREFIX=/usr/local/redis install 执行安装脚本 cd /opt/redis-5.0.7/utils ./install_server.sh 注意：当提示选择redis可执行文件路径时，指定为/usr/local/redis/bin/redis-server 创建软链接 ln -s /usr/local/redis/bin/* /usr/local/bin/

2.2Master节点配置

vim /etc/redis/6379.conf 需要修改的配置项： bind 0.0.0.0 # 70行，修改监听地址为0.0.0.0 daemonize yes # 137行，开启守护进程 logfile /var/log/redis_6379.log # 172行，指定日志文件目录 dir /var/lib/redis/6379 # 264行，指定工作目录 appendonly yes # 700行，开启AOF持久化功能 重启服务 /etc/init.d/redis_6379 restart

2.3Slave节点配置

vim /etc/redis/6379.conf 需要修改的配置项： bind 0.0.0.0 # 70行，修改监听地址为0.0.0.0 daemonize yes # 137行，开启守护进程 logfile /var/log/redis_6379.log # 172行，指定日志文件目录 dir /var/lib/redis/6379 # 264行，指定工作目录 replicaof 192.168.10.110 6379 # 288行，指定要同步的Master节点IP和端口 appendonly yes # 700行，开启AOF持久化功能 重启服务 /etc/init.d/redis_6379 restart

2.4验证主从效果

在Master节点查看日志：

tail -f /var/log/redis_6379.log # 应看到类似以下内容： # Replica 192.168.10.120:6379 asks for synchronization # Replica 192.168.10.123:6379 asks for synchronization

在Master节点验证从节点状态：

redis-cli info replication 输出示例： Replication role:master connected_slaves:2 slave0:ip=192.168.10.120,port=6379,state=online,offset=1246,lag=0 slave1:ip=192.168.10.123,port=6379,state=online,offset=1246,lag=1

在Master节点插入一条数据验证结果：

# 在Master节点插入一条数据 set master 192.168.10.110 # 在slave节点查看数据 get master

三、Redis哨兵模式

3.1配置哨兵模式（所有节点操作）

vim /opt/redis-5.0.7/sentinel.conf 需要修改的配置项： protected-mode no # 17行，关闭保护模式 port 26379 # 21行，Redis哨兵默认的监听端口 daemonize yes # 26行，指定sentinel为后台启动 logfile "/var/log/sentinel.log" # 36行，指定日志存放路径 dir "/var/lib/redis/6379" # 65行，指定数据库存放路径 sentinel monitor mymaster 192.168.10.110 6379 2 # 84行，指定监控的主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移 sentinel down-after-milliseconds mymaster 30000 # 113行，判定服务器down掉的时间周期，默认30000毫秒（30秒） sentinel failover-timeout mymaster 180000 # 146行，故障节点的最大超时时间（180秒）

3.2启动哨兵模式

注意：先启动master，再启动slave

cd /opt/redis-5.0.7/ redis-sentinel sentinel.conf &

3.3查看哨兵信息

redis-cli -p 26379 info Sentinel 输出示例： Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.10.110:6379,slaves=2,sentinels=3

3.4故障模拟测试

# 查看redis-server进程号 ps -ef | grep redis 杀死Master节点上redis-server的进程 kill -9 $(cat /var/run/redis_6379.pid) 查看哨兵日志，观察故障转移过程 tail -f /var/log/sentinel.log 验证master是否被切换 redis-cli -p 26379 INFO Sentinel

四.Redis 群集模式

4.1创建集群配置文件（每台机器两个实例）

以192.168.10.110为例，创建两个配置文件：

主节点 6379

mkdir -p /etc/redis/cluster/6379 /etc/redis/cluster/6380 cp /opt/redis-5.0.7/redis.conf /etc/redis/cluster/6379/redis.conf cp /opt/redis-5.0.7/redis.conf /etc/redis/cluster/6380/redis.conf

修改 6379 配置（主节点）

vim /etc/redis/cluster/6379/redis.conf

修改以下内容：

bind 0.0.0.0 protected-mode no port 6379 daemonize yes cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000 appendonly yes

修改 6380 配置（从节点）

vim /etc/redis/cluster/6380/redis.conf

修改以下内容：

bind 0.0.0.0 protected-mode no port 6380 daemonize yes cluster-enabled yes cluster-config-file nodes-6380.conf cluster-node-timeout 15000 appendonly yes

4.2在另外两台机器上重复步骤3

• 192.168.10.111：同样创建 6379（主）、6380（从）

• 192.168.10.112：同样创建 6379（主）、6380（从）

4.3启动所有Redis实例（三台机器）

redis-server /etc/redis/cluster/6379/redis.conf redis-server /etc/redis/cluster/6380/redis.conf

检查进程：

ps -ef | grep redis

4.4组建集群（在一台机器上执行即可）

在192.168.10.110上执行：

redis-cli --cluster create \ 192.168.10.110:6379 \ 192.168.10.111:6379 \ 192.168.10.112:6379 \ 192.168.10.111:6380 \ 192.168.10.112:6380 \ 192.168.10.110:6380 \ --cluster-replicas 1

⚠️注意顺序：

• 前三个是主节点（110:6379, 111:6379, 112:6379）

• 后三个是从节点（111:6380, 112:6380, 110:6380）

• 这样分配后：

  • 110:6379 的从节点是 111:6380（不是本机 ✅）

  • 111:6379 的从节点是 112:6380（不是本机 ✅）

  • 112:6379 的从节点是 110:6380（不是本机 ✅）

执行后会提示分配哈希槽，输入yes确认。

4.5验证集群状态

redis-cli -h 192.168.10.110 -p 6379 cluster nodes

或查看详细信息：

redis-cli -h 192.168.10.110 -p 6379 cluster info

查看主从关系：

redis-cli -h 192.168.10.110 -p 6379 info replication

4.6测试数据写入

redis-cli -h 192.168.10.110 -p 6379 -c set name zhangsan redis-cli -h 192.168.10.110 -p 6379 -c get name

五.故障测试

测试场景：主节点宕机（模拟 M1 故障）

# 在主机A（192.168.10.110）上停止主节点 M1 ps -ef | grep redis | grep 6379 kill -9 <M1进程PID>

日志记录

# 从节点 S1（192.168.10.111:6380）日志 23062:x 08 Aug 2026 10:15:30.123 # +sdown master mymaster 192.168.10.110 6379 23062:x 08 Aug 2026 10:15:35.456 # +new-epoch 1 23062:x 08 Aug 2026 10:15:35.457 # +vote-for-leader 0fef2cc38d8db8cc... 1 23062:x 08 Aug 2026 10:15:38.789 # +switch-master mymaster 192.168.10.110 6379 192.168.10.111 6380 23062:x 08 Aug 2026 10:15:38.790 * +slave slave 192.168.10.112:6380 192.168.10.112 6380 @ mymaster 192.168.10.111 6380 23062:x 08 Aug 2026 10:15:38.790 * +slave slave 192.168.10.110:6379 192.168.10.110 6379 @ mymaster 192.168.10.111 6380

故障转移后集群状态

redis-cli -h 192.168.10.111 -p 6380 cluster nodes

查看新的主节点

# 通过任意可用节点查看集群状态 redis-cli -h 192.168.10.111 -p 6379 cluster nodes

# 在111机器上执行 redis-cli -h 192.168.10.111 -p 6380 info replication

六.redis说明

6.1 为什么选择该架构

①业务需求分析

②架构选型对比

③选择本方案的核心原因

1. 数据分片，突破单机内存瓶颈：3个主节点分担数据存储，总容量是单机的3倍

2. 跨主机高可用：每个主节点的从节点都在其他机器上，单机宕机不影响整体服务

3. 读写性能提升：3主3从，读操作可由从节点分担，提升并发能力

4. 自动故障转移：主节点宕机后，哨兵机制自动选举从节点升级为主节点

5. 满足「主从不同机」的容灾要求：物理隔离，避免单点故障导致数据全部丢失

6.2拓扑关系简图

6.3节点角色说明

七.总结

本文详细介绍了 Redis 高可用集群的完整搭建过程，涵盖了从基础环境准备到三种核心架构模式的实践操作：

1. 环境准备与主从复制

• 完成了三台服务器（192.168.10.110/111/112）的基础环境配置
• 成功搭建了 Redis 主从复制架构，实现了数据同步和读写分离
• 通过日志监控和命令验证确保了主从同步的正常运行

2. 哨兵模式实现高可用

• 配置并启动了 Redis Sentinel 哨兵集群
• 实现了主节点故障时的自动故障转移
• 通过故障模拟测试验证了哨兵模式的可靠性

3. Redis Cluster 集群部署

• 在三台机器上分别部署了主从实例（每台机器 6379 主 + 6380 从）
• 成功组建了 3 主 3 从的 Redis 集群
• 实现了数据分片存储，突破了单机内存限制
• 验证了集群状态和数据读写功能

4. 架构优势与特点

• 高可用性：任意节点故障不影响整体服务
• 数据安全：跨主机备份，避免单点故障导致数据丢失
• 性能扩展：读写分离 + 数据分片，支持水平扩展
• 自动运维：哨兵机制实现自动故障检测和转移

5. 关键注意事项

1. 集群组建时注意节点顺序，确保主从节点分布在不同的物理机上
2. 哨兵配置中的 quorum 参数需要根据实际节点数量合理设置
3. 故障转移后需要验证新的主从关系和数据一致性
4. 生产环境建议配置监控告警，及时发现和处理异常

通过本文的实践，读者可以掌握 Redis 从单机部署到高可用集群的完整技术栈，为生产环境中的 Redis 应用提供可靠的技术保障。这套架构方案既满足了数据安全和高可用的需求，又具备了良好的扩展性，是构建大规模 Redis 应用的理想选择。