企业官网建设流程全解析

一、Redis主从复制

1. 理解主从复制

你可以把Redis主从复制想象成「老板和秘书」的关系：

• 主库（master）：就是老板，负责所有「写操作」（新增、修改、删除数据），手里有最全的业务笔记（数据）；
• 从库（slave/replica）：就是秘书，只做「读操作」（查询数据），会实时抄老板的笔记，保证自己的笔记和老板一致；
• 客户要查数据时，优先找秘书（从库），老板只专注写，这样老板的工作量就少了，整体效率更高，而且如果老板临时有事（主库宕机），秘书手里也有完整数据，能临时顶包查数据。

2. 主从复制的核心原理（分3阶段，大白话）

Redis主从复制本质是「从库主动同步主库数据」，分3步：

1. 握手阶段（建立连接）：从库主动给主库发消息：“老板，我要抄你的笔记了！”，主库确认后，两者建立长连接；
2. 全量同步（第一次抄笔记）：如果是从库第一次同步，主库会把自己所有数据打包成一个「快照文件」（RDB文件）发给从库，从库先清空自己的笔记，再加载这个快照，保证和主库初始数据一致；
3. 增量同步（实时抄笔记）：全量同步后，主库每做一次写操作（比如改了一条数据），就会把这个操作指令实时发给从库，从库跟着执行一遍，保证数据和主库实时一致。

3. Linux下主从复制演示步骤（已装Redis）

假设你已经安装好Redis（默认路径/usr/local/redis，配置文件redis.conf），演示「1主1从」：

步骤1：准备主库（默认Redis实例，端口6379）

主库默认不用改核心配置，只需要确保：

# 编辑主库配置文件（6379端口）vim/usr/local/redis/redis.conf# 确认以下配置（没有就添加）：bind0.0.0.0# 允许其他机器连接（如果是本机演示，127.0.0.1也可以）protected-mode no# 关闭保护模式（测试用，生产要配密码）port6379# 主库端口daemonizeyes# 后台运行pidfile /var/run/redis_6379.pid logfile"6379.log"dbfilename dump_6379.rdb# 启动主库/usr/local/redis/src/redis-server /usr/local/redis/redis.conf

步骤2：准备从库（新建6380端口的Redis实例）

# 复制一份配置文件给从库cp/usr/local/redis/redis.conf /usr/local/redis/redis_6380.conf# 编辑从库配置文件vim/usr/local/redis/redis_6380.conf# 修改以下配置（和主库区分）：bind0.0.0.0 protected-mode no port6380# 从库端口，和主库不一样daemonizeyespidfile /var/run/redis_6380.pid logfile"6380.log"dbfilename dump_6380.rdb# 核心：指定主库地址和端口（关键配置！）replicaof127.0.0.16379# Redis5.0+用replicaof，5.0前用slaveof# 启动从库/usr/local/redis/src/redis-server /usr/local/redis/redis_6380.conf

步骤3：验证主从复制是否生效

# 1. 连接主库（6379），写入数据/usr/local/redis/src/redis-cli -p6379127.0.0.1:6379>setname"redis-master"# 主库写数据OK# 2. 连接从库（6380），查询数据/usr/local/redis/src/redis-cli -p6380127.0.0.1:6380>get name# 从库能查到主库写的数据，说明同步成功"redis-master"# 3. 验证从库不能写数据（从库默认只读）127.0.0.1:6380>setage18(error)READONLY You can'twriteagainst areadonly replica.# 报错，只读# 4. 查看主从状态（主库执行）127.0.0.1:6379>info replication# 能看到"connected_slaves:1"，以及从库的端口6380，说明主从连接成功

二、Redis哨兵模式

1. 理解哨兵模式

主从复制解决了「读写分离」，但有个大问题：如果老板（主库）突然病倒了（宕机），虽然秘书（从库）能查数据，但没人能写数据了，业务会卡住。

哨兵模式就相当于给老板配了「专职保镖」（哨兵进程）：

• 保镖（sentinel）会一直盯着老板和秘书的状态（每秒发心跳包）；
• 如果发现老板宕机了，保镖会从所有秘书里选一个「最靠谱的」（通过投票）升级成新老板；
• 然后通知其他秘书：“别抄旧老板了，以后抄新老板的笔记！”；
• 等旧老板康复（主库重启），也不能再当老板了，只能降级成秘书，抄新老板的笔记。

2. 哨兵模式的核心作用

• 监控：实时检查主库、从库是否活着；
• 自动故障转移：主库挂了，自动选新主库，不用人工干预；
• 通知：把故障和切换结果告诉运维人员（比如发邮件、短信）。

3. 哨兵模式的简单工作逻辑

1. 哨兵进程启动后，先和主库建立连接，获取所有从库的信息；
2. 哨兵每秒给主/从库发「PING」命令，超过一定时间没回应，就标记主库“主观下线”；
3. 如果多个哨兵（一般至少3个）都认为主库“主观下线”，就标记为“客观下线”；
4. 哨兵们投票选一个从库当新主库，然后命令其他从库同步新主库，旧主库重启后变成从库。

三、Redis集群

1. 理解Redis集群

主从+哨兵解决了「高可用」，但如果数据量太大（比如100G），一个主库存不下，或者每秒要处理10万次请求，一个主库扛不住，这时候就需要Redis集群。

你可以把Redis集群想象成「连锁超市」：

• 单节点Redis：就是一家小超市，老板一个人又收钱又理货，人多了就挤不动，货多了仓库也装不下；
• Redis集群：就是连锁超市，分成多个分店（节点），每个分店有一个店长（主节点）和店员（从节点）；
• 顾客（数据）按「门牌号」（哈希槽）分配到不同分店：比如0-5460号哈希槽归分店A，5461-10922号归分店B，10923-16383号归分店C；
• 每个分店只负责自己的顾客，店长管写，店员管读，就算一家分店关门（节点宕机），其他分店还能正常营业，而且有店员顶包。

2. 为什么要用Redis集群？

• 解决容量瓶颈：单Redis节点最多存几G/几十G数据，集群可以把数据分散到多个节点，存几百G甚至T级数据；
• 解决性能瓶颈：单节点QPS（每秒请求数）大概几万，集群能把请求分散到多个节点，QPS能提升到几十万；
• 更高的可用性：集群里一个主节点宕机，它的从节点会自动升级成主节点，而且其他节点不受影响，比哨兵模式的容错性更强。

3. Linux下Redis集群搭建步骤（6节点：3主3从）

Redis集群要求至少3个主节点，每个主节点配1个从节点（共6节点），端口用7000-7005。

步骤1：准备集群目录和配置文件

# 1. 创建集群目录mkdir-p /usr/local/redis/cluster/{7000,7001,7002,7003,7004,7005}# 2. 复制配置文件到每个节点目录（以7000为例，其他节点改端口即可）cp/usr/local/redis/redis.conf /usr/local/redis/cluster/7000/redis.conf# 3. 编辑7000节点的配置文件vim/usr/local/redis/cluster/7000/redis.conf# 修改以下核心配置：bind0.0.0.0 protected-mode no port7000daemonizeyespidfile /var/run/redis_7000.pid logfile"7000.log"dbfilename dump_7000.rdbdir/usr/local/redis/cluster/7000# 节点数据目录cluster-enabledyes# 开启集群模式（关键！）cluster-config-file nodes_7000.conf# 集群节点配置文件（自动生成）cluster-node-timeout15000# 节点超时时间（15秒）appendonlyyes# 开启AOF持久化（可选，增强数据可靠性）# 4. 复制7000的配置文件到7001-7005，批量修改端口（用sed命令）forportin{7001..7005};docp/usr/local/redis/cluster/7000/redis.conf /usr/local/redis/cluster/$port/redis.confsed-i"s/7000/$port/g"/usr/local/redis/cluster/$port/redis.confdone

步骤2：启动所有集群节点

# 批量启动6个节点forportin{7000..7005};do/usr/local/redis/src/redis-server /usr/local/redis/cluster/$port/redis.confdone# 检查节点是否启动成功ps-ef|grepredis|grep-vgrep# 能看到6个redis进程，端口7000-7005，说明启动成功

步骤3：创建Redis集群（Redis5.0+用redis-cli --cluster）

# 执行集群创建命令（127.0.0.1是本机IP，生产改实际IP；--cluster-replicas 1表示每个主节点配1个从节点）/usr/local/redis/src/redis-cli --cluster create127.0.0.1:7000127.0.0.1:7001127.0.0.2:7002127.0.0.1:7003127.0.0.1:7004127.0.0.1:7005 --cluster-replicas1# 执行后会提示分配哈希槽，输入「yes」确认：>>>Performinghashslots allocation on6nodes...>>>Assign a different config epoch to eachnode>>>Sending CLUSTER MEET messages tojointhe cluster Do you want to accept the proposed configuration?(type'yes'to accept):yes

步骤4：验证集群是否搭建成功

# 连接集群（-c表示集群模式）/usr/local/redis/src/redis-cli -c -p7000# 1. 查看集群状态127.0.0.1:7000>cluster info# 能看到"cluster_state:ok"，说明集群正常# 2. 查看集群节点127.0.0.1:7000>cluster nodes# 能看到6个节点，标记为master（主）或slave（从），以及哈希槽分配# 3. 测试数据写入（集群会自动把数据分配到对应主节点）127.0.0.1:7000>setuser:1"zhangsan"OK# 查数据，集群会自动路由到存储该数据的节点127.0.0.1:7000>get user:1"zhangsan"# 4. 测试故障转移（停掉一个主节点，比如7000）# 先退出redis-cli，执行：/usr/local/redis/src/redis-cli -p7000shutdown# 再连接7001，查看集群状态：/usr/local/redis/src/redis-cli -c -p7001127.0.0.1:7001>cluster nodes# 能看到7000的从节点（比如7003）升级成了主节点，集群状态还是ok

总结

1. 主从复制：核心是「读写分离+数据备份」，从库同步主库数据，主写从读，提升并发；
2. 哨兵模式：核心是「主库故障自动切换」，解决主从复制的“主库宕机无主”问题，保证高可用；
3. Redis集群：核心是「分片存储+分布式高可用」，解决单节点容量/性能瓶颈，数据按哈希槽分散到多个主节点，每个主节点有从节点容错。

三个功能的递进关系：主从复制（基础）→ 哨兵模式（主从的高可用增强）→ 集群（大规模场景的分布式解决方案）。