企业官网建设流程全解析

一、先搞懂：我们为什么需要Redis集群？

先回忆之前学的架构，单机Redis、一主多从+哨兵模式都有明显短板，这也是集群诞生的核心原因：

1. 容量瓶颈
   单台Redis内存有限，百万级商品、用户缓存根本存不下，主从只是复制数据，不能扩容存储空间，数据只能存在主节点一台机器。
2. 并发上限低
   所有写操作只能打在唯一主节点，海量秒杀、首页缓存场景下单节点CPU、网络IO直接打满，无法分摊写压力。
3. 主从哨兵有硬伤
   哨兵只能做故障自动切换，不能水平分片存储数据，所有key全量存在主库，扩容只能换更高配置服务器，成本极高，无法分布式横向拓展。

Redis Cluster（3.0推出无中心化集群）完美解决两大痛点：数据分片存储、读写分布式扩容，同时自带主从故障自动切换，是企业生产主流缓存架构。

二、Redis集群核心底层：16384哈希槽是什么？

这是集群最核心的概念，考试、面试必考点，我当初理解了半天才通透！

1. 槽位总数固定16384（0~16383）
   Redis把所有缓存key均匀划分到16384个哈希槽，每个主节点负责一部分槽，数据按槽分片存放。
2. key归属计算规则
   CRC16(key) % 16384
   通过CRC16算法算出key的校验值，对16384取模，得到这个key对应的哈希槽编号，客户端自动路由到对应主节点读写。
3. 分片示例（3主架构）

• 主节点1：0 ~ 5460 槽
• 主节点2：5461 ~ 10922 槽
• 主节点3：10923 ~ 16383 槽

每个主节点搭配从节点（标准3主3从），一个槽的主节点宕机，对应从自动升级为主，保证数据不丢失、集群可用。

小坑提醒

集群环境下，不在同一个哈希槽的多个key，不能用mset、mget批量操作，直接报CROSSSLOT跨槽错误！
解决方案：哈希标签{分组标识}，大括号内内容参与哈希计算，相同大括号的key会落到同一个槽：

mset user{order}:1 zhang user{order}:2 li

两个key都根据order计算槽位，支持批量操作。

三、实操：CentOS7搭建3主3从Redis集群

课程里用6个Redis实例，端口6379/6380/6381（主）、6389/6390/6391（从），全程命令亲测可用，报错点全部标注！

前置准备

1. 已编译安装Redis6.2.1，gcc环境正常
2. 关闭防火墙/开放6379~6391端口
3. 注释bind 127.0.0.1，关闭保护模式protected-mode no，否则外部/集群节点无法通信

步骤1：创建集群目录与独立配置文件

# 新建集群文件夹mkdirredis-cluster&&cdredis-cluster# 拷贝基础redis配置cp/opt/redis-6.2.1/redis.conf ./

复制6份配置，分别修改端口、pid、rdb文件名，必须开启集群三大参数（核心配置）：

# 开启集群模式 cluster-enabled yes # 集群节点信息存储文件，每个实例名字区分 cluster-config-file nodes-6379.conf # 节点失联超时15秒，超时触发主从切换 cluster-node-timeout 15000

批量替换端口小技巧：vim全局替换:%s/6379/6380，6份文件快速改完。

步骤2：启动6个Redis节点

redis-server redis6379.conf redis-server redis6380.conf redis-server redis6381.conf redis-server redis6389.conf redis-server redis6390.conf redis-server redis6391.conf# 查看进程确认全部启动ps-ef|grepredis

启动成功后目录自动生成nodes-xxxx.conf节点记录文件。

步骤3：一键创建集群（重点易错点）

进入redis源码src目录执行创建命令，必须写服务器真实IP，不能127.0.0.1，否则集群节点互通失败：

cd/opt/redis-6.2.1/src redis-cli--clustercreate192.168.10.130:6379192.168.10.130:6380192.168.10.130:6381192.168.10.130:6389192.168.10.130:6390192.168.10.130:6391 --cluster-replicas1

参数解释：
--cluster-replicas 1：每个主节点分配1个从节点，3主3从完美架构。
执行后输入yes确认哈希槽分配，出现All 16384 slots covered代表集群搭建成功！

步骤4：集群客户端连接（-c参数不能丢）

# -c 开启集群自动重定向，无此参数跨槽读写报错redis-cli-c-p6379# 查看集群全部节点信息cluster nodes# 查看指定key所属哈希槽cluster keys k1

写入测试：set k1 v1，终端会自动提示重定向到对应节点，集群路由机制生效。

四、集群故障自动恢复机制（面试高频）

场景1：单个主节点宕机（如6379下线）

1. 集群其他节点检测到6379超时失联；
2. 6379对应的从节点（6390）自动升级为主节点，接管0~5460所有哈希槽；
   3 原有主节点6379重启后，自动变成新主6390的从节点；
3. 整个集群正常读写，无停机。

场景2：某一组主从全部宕机

由配置cluster-require-full-coverage控制：

1. yes（默认）：16384槽无法全部覆盖，整个集群直接不可用；
2. no：仅丢失该组槽的数据无法读写，其余节点正常工作。
   生产环境建议改为no，降低整体故障影响范围。

五、集群优缺点总结

优点

1. 数据分片存储，横向扩容内存，突破单机容量限制；
2. 读写分离+分布式分摊并发，写压力分散到多主节点；
3. 内置主从复制+自动故障转移，无需额外部署哨兵；
4. 无中心化架构，任意节点可接收客户端请求，自动路由。

缺点

1. 多键批量操作限制，无哈希标签无法跨槽mget/mset；
2. 事务仅支持单个哈希槽内key，跨槽不支持事务；
3. 搭建、运维复杂度高于单机、哨兵架构；
4. 批量数据备份、扩容迁移操作流程更繁琐。

六、学习复盘：集群、主从、哨兵三者怎么选？

很多同学学完混淆，一张表分清适用场景：

Redis集群总结

一、为什么要用Redis集群

单机内存、并发上限低；一主多从哨兵仅实现故障切换，无法拆分数据横向扩容。Redis Cluster为3.0推出的无中心化集群，同时实现数据分片存储、分布式分摊读写压力，自带主从自动容灾。

二、核心原理：16384哈希槽

1. 固定0~16383共16384个哈希槽，通过CRC16(key)%16384计算key归属槽位，分散存储到多台主节点；
2. 标准部署3主3从，每个主节点搭配一台从机，主节点宕机时对应从自动升级为主；
3. 不同槽位key不能执行mset/mget，使用哈希标签{xxx}，大括号内字符参与哈希计算，让多key落到同一槽，支持批量操作。

三、CentOS7搭建实操要点

1. 6个实例：6379/6380/6381为主，6389/6390/6391为从，配置文件必须开启cluster-enabled yes等集群三项核心参数；
2. 创建集群命令必须填写服务器真实内网IP，禁止127.0.0.1；--cluster-replicas 1代表每个主分配1台从；
3. 客户端连接集群需加-c参数，开启槽位自动重定向；
4. 故障规则：cluster-require-full-coverage=yes时任意一组主从全宕，整个集群不可；改为no，仅对应槽位数据无法访问，其余正常。

四、集群优缺点

优点

数据分片突破单机内存与并发瓶颈；内置主从复制，无需额外部署哨兵；无中心化，任意节点均可接收客户端请求。

缺点

跨槽多键、事务存在使用限制；部署、运维复杂度高于单机、哨兵架构。

五、SpringBoot整合Redis集群

引入redis启动器与连接池依赖，yml配置集群全部节点地址；自定义RedisTemplate，使用String序列化key、Jackson序列化value解决乱码，模板底层自动完成哈希槽路由，无需手动计算。

六、三种Redis架构适用场景

1. 单机：小型项目、本地测试，低并发低数据量；
2. 主从+哨兵：中小型项目，只需高可用，无需海量数据扩容；
3. Redis集群：大型互联网项目，高并发、海量缓存，需要分布式分片扩容。

七、学习总结

哈希分片是分布式中间件通用设计思路；实操高频踩坑点：localhost集群互通失败、忘记-c参数、跨槽执行批量指令；哈希槽、集群搭建、架构对比是期末、后端面试核心考点。