【Redis】高可用集群架构

- 一，主从复制------读写分离
- - 1.概念
  - 2.如何做的（单机多实例模拟）？
- 二，哨兵模式
- - 1.概念
  - 2.在虚拟机中实操
- 三，分片集群
- - 1.概念
  - - [1.1 基础理论](#1.1 基础理论)
    - [1.2 MOVED重定向机制](#1.2 MOVED重定向机制)
    - [1.3 去中心化](#1.3 去中心化)
    - [1.4 关于两个细节](#1.4 关于两个细节)
  - 2.关于在虚拟机中单机部署模拟集群架构

在之前提到：应对缓存雪崩最好的办法就是搭建集群，因为在线上生产环境中，单机版redis是非常脆弱的。

主要有两个方面：

硬件隐患：万一运行redis的服务器断电，网线被踢，整个系统就会瘫痪。
性能瓶颈：单台服务器的内存是有限的，如果公司有500g的海量数据，单机根本装不下。

为了解决"高可用（不死机）"和"高扩展（多存数据）"的问题，Redis 演进出了三种完美的分布式架构形态。

接下来，我们就要按照下面这张图一步一步解决这两个问题：

bash 复制代码

┌───────────────────────────────┐
  │      第一阶段：主从复制       │ ◄─── 解决了【读并发瓶颈】和【数据备份】
  └───────────────┬───────────────┘
                  │ 🚨 致命痛点：Master一旦挂了，全网无法写入！
                  │             必须靠人工半夜爬起来手动提拔 Slave 充当老大。
                  ▼
  ┌───────────────────────────────┐
  │      第二阶段：哨兵模式       │ ◄─── 解决了【无人值守的自动故障转移】
  └───────────────┬───────────────┘
                  │ 🚨 致命痛点：所有的机器存的都是"全量一模一样"的数据。
                  │             如果公司有 1TB 海量数据，内存单机直接挤爆！
                  ▼
  ┌───────────────────────────────┐
  │    第三阶段：分片集群(Cluster) │ ◄─── 解决了【单机内存极限】与【写并发瓶颈】
  └───────────────────────────────┘      实现数据切片分布式存储，横向无限扩展。

一，主从复制------读写分离

1.概念

主从复制是 Redis 实现高可用和数据冗余的基础机制。简单说，就是把一台 Redis 服务器（主节点）的数据实时同步到其他一台或多台服务器（从节点）。

角色定义

主节点（Master）：接收客户端写请求（SET、DEL 等），负责处理所有数据变更。
从节点（Slave / Replica）：连接主节点，复制主节点的数据，对外可提供只读服务（如 GET、LRANGE）。

一个主节点可以有多个从节点，从节点也可以拥有自己的从节点（级联复制）。

复制过程

从节点发起同步：从节点向主节点发送 SYNC（旧版）或 PSYNC（新版）命令，请求数据。

主节点生成 RDB 快照：主节点执行 bgsave，生成一个当前时刻的 RDB 文件，同时将生成期间的写命令缓存下来。

从节点载入 RDB：主节点把 RDB 文件发送给从节点，从节点清空自身数据，然后载入 RDB，恢复到主节点的快照状态。

增量复制：主节点把缓存的新写命令以及后续收到的写命令，持续发送给从节点，从节点执行这些命令，保持与主节点数据一致。

如果网络断开又重连，Redis 2.8 之后支持部分重同步，只同步断开期间丢失的命令，不需要重新传输整个 RDB。

主要用途

读写分离：主节点处理写，从节点分担读压力，提高系统吞吐。
数据冗余：主节点故障时，从节点可提升为新主，防止数据丢失。
离线计算：在从节点上执行耗时操作（如 BGSAVE、SORT），不影响主节点性能。

重要特性

异步复制：主节点写成功后立即返回客户端，再异步把命令传播给从节点。因此从节点数据可能会有短暂延迟，但性能好。
复制不阻塞：主节点在生成 RDB 期间仍可正常处理请求；从节点在载入 RDB 期间会阻塞（旧版本），新版本可以非阻塞加载。
可配置读写分离：默认从节点是只读的（replica-read-only yes），避免误写。
故障自动切换：单独的主从复制不会自动切换。需要配合 Redis Sentinel 或 Cluster 实现自动 failover。

2.如何做的（单机多实例模拟）？

现在我们需要在一台主机上，使用两个端口来模拟主从复制。

现在是liunx环境，在/etc/redis/文件夹下，我们需要有两个配置文件，一个主机6379，一个从机6380。

首先如果已经有了redis.conf，在里面确保有以下参数：

bash 复制代码

daemonize yes
bind 0.0.0.0
protected-mode no
dir /var/lib/redis
appendonly yes
appendfsync everysec

然后创建一个redis_6380.conf，在里面确保有以下参数：

bash 复制代码

daemonize yes
port 6380
bind 0.0.0.0
protected-mode no
dir /var/lib/redis6380
appendonly yes
appendfsync everysec
replicaof 127.0.0.1 6379

讲解一下这里参数的意思：

daemonize yes：开启后台守护进程的运行

port 6380：告诉这个redis进程在哪个窗口工作。

dir /var/lib/redis：这就是设置了数据存放的目录。无论rdb快照文件，还是aof日记文件，或者是reids7.0的appendlydir文件夹，所有redis生成的硬盘文件都会老老实实存放在这个绝对路径下。这里应该设置不同的文件，否则可能导致覆盖错乱。

bind 0.0.0.0 ：这意味着放行所有网络网卡。

protected-mode no：关闭保护模式。如果开启，且没设密码，没有配置bind时，外界的电脑连不进来。

appendonly yes：开启aof'记日记'持久化。

appendfsync everysec：每秒强制写一次硬盘。

replicaof ：这个就是这里的关键了，认老大。启动后，6380会给6379发起tcp连接，并执行全量数据同步。

写完配置文件之后，就可以启动redis服务了。

bash 复制代码

# 1. 启动主机
redis-server /etc/redis/redis.conf

# 2. 启动从机
redis-server /etc/redis/redis_6380.conf

现在执行以下代码，应该可以看见两个redis进程。

bash 复制代码

ps -ef | grep redis

现在，我们就可以去测试主从复制了。

执行以下代码：

bash 复制代码

redis-cli -p 6379 info replication

我们会得到一堆关于Replication的信息，但只要看到role，connected_slaves,slave0这三个参数像下面这样，就说明成功了。

注意，现在只是单机多实例模拟，在实际的业务中，绝对不可能吧主从放到一台机器上，因为这台机器物理或硬盘坏了，那就完全失去了意义。

我们可以看到，虽然主从结构解决了数据全在一台机器上可能不安全（高可用）和读扩展（读写分离）的问题，但是他还没有解决如果数据过大该怎么办（每个从库仍然需要存储完整的数据副本，所以总数据量超过单机磁盘容量时，主从架构依然无能为力），还有如果主机挂了，实际上是需要管理员来提升从机的，较为麻烦。

二，哨兵模式

1.概念

主从复制虽然实现了读写分离，但它是个没有自我修复能力的残疾架构。

为什么这么说？

因为主机挂了必须人工干预，所以我们需要哨兵模式，它相当于给redis主从系统请了一群24小时不眨眼的职业保安团。

Sentinel（哨兵）是一个独立运行的进程，它不存储业务数据，只做一件事：监控你的主从实例，发现主库挂了就自动选一个新主库，并通知客户端。

哨兵模式的结构：

bash 复制代码

 ┌──────────────────────────────────────────────────────────────────────────────────────┐
 │                              客户端 / 后端应用 (Java / Go / Node)                     │
 └───────────────────────────────────────┬──────────────────────────────────────────────┘
                                         │ ① 首次连接先问哨兵："谁是主节点？"
                                         │ ② 哨兵返回当前 Master 的真实 IP
                                         ▼
 ┌──────────────────────────────────────────────────────────────────────────────────────┐
 │                          【 哨兵集群 / 保安团 (Sentinel Cluster) 】                   │
 │                                                                                      │
 │     ┌──────────────┐         PING 心跳 (每秒)         ┌──────────────┐              │
 │     │  哨兵 1 (S1)  ├────────────────────────────────►│  哨兵 2 (S2)  │              │
 │     └──────┬───────┘                                 └──────┬───────┘              │
 └────────────┼────────────────────────────────────────────────┼────────────────────────┘
              │                                                │
              │ ③ 监控 Master 状态                              │ ③ 发现 Master 挂了
              │ 发现不理 PING ➔ 【主观下线】                   │ 哨兵间投票 ➔ 【客观下线】
              ▼                                                ▼
 ┌───────────────────────────┐                    ┌───────────────────────────┐
 │   旧主节点 (Master 6379)  │                    │   从节点 (Slave 6380)     │
 │                           │                    │                           │
 │     ❌ 突发断电/宕机       │                    │   💡 经过哨兵"军功章算法" │
 │                           │                    │   海选，被自动提拔为：    │
 └───────────────────────────┘                    └────────────┬──────────────┘
                                                               │
                                                               │ ④ 哨兵发出命令：
                                                               │   升级为新 Master！
                                                               ▼
                                                  ┌───────────────────────────┐
                                                  │  👑 新主节点 (Master 6380) │
                                                  │   (开始接收客户端的写请求) │
                                                  └───────────────────────────┘

哨兵通常部署三个或者更多，而且是奇数个，为了避免脑裂或者平票。

哨兵之间会互相通信，形成一个小集群，投票决定主库是否真挂了，以及由哪个哨兵来执行故障转移。

哨兵主要会做以下三件事：

监控

每隔一秒（可配置）向主库、从库、其他哨兵发送 PING，看它们是否还活着。
通知

如果某个实例响应异常，哨兵会通过发布订阅（Pub/Sub）通知其他哨兵和客户端（可选）。
自动故障转移

当主库被多数哨兵判定为客观下线后，哨兵领导者会执行：
- 从从库中选出一个新主库。
- 让其他从库去复制新主库。
- 通知客户端新的主库地址。

简易版的故障转移的流程讲解：

主观下线

某个哨兵 A 发现主库 PING 超时 → 标记为"主观下线"。

客观下线

哨兵 A 询问其他哨兵："主库是不是挂了？"

如果收到足够多（超过半数，且可配置）的哨兵确认主库挂了 → 标记为"客观下线"。

选举领导者哨兵

哨兵们投票选出一个哨兵（比如 B）来执行故障转移。

（这就是为什么至少需要 3 个哨兵 ------ 确保能选出多数派）

选新主库

领导者哨兵根据规则从从库中挑选一个作为新主库：

优先选优先级高的（配置 slave-priority）。
然后选数据最接近原主库的（复制偏移量最大）。
再选 run_id 小的（作为最终决定）。

切换

让新主库执行 SLAVEOF no one 变成主库。
让其他从库指向新主库。
把原主库（如果后来复活）变成新主库的从库。

通知客户端

哨兵会将新主库地址通过 +switch-master 事件发送给订阅的客户端（例如 Jedis、Lettuce 等会收到通知并自动切换）。

每个哨兵本身就是一个进程，如果部署了三个哨兵，服务器上就会看见三个redis-sentinel进程。

为什么不放一起呢？因为哨兵的容错前提就是进程少数派进程失败不会影响整体，如果多个进程在一起，一个进程一挂就相当于多个哨兵同时失效。

虽然只要端口不冲突，可以在一台机器上运行多个哨兵进程。但是生产环境不推荐，因为机器本身是单点。

2.在虚拟机中实操

基于上面的主从结构，现在添加上一个哨兵来监控它们。

1. 手写哨兵配置文件 sentinel.conf

在 root 用户下，直接执行下面这行纯净版命令，创建并写入哨兵配置：

bash 复制代码

cat << 'EOF' > /etc/redis/sentinel.conf
port 26379
daemonize yes
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
EOF

这 6 行参数的含义：

port 26379：哨兵进程专属的监听端口，默认是 26379。
daemonize yes：让哨兵也在 Linux 后台静默运行。
sentinel monitor mymaster 127.0.0.1 6379 1：核心命令！告诉哨兵："你去给我死死盯着本地 6379 端口的那个 Master，我给它起名叫 mymaster"。最后的 1 就是法定票数（Quorum）。因为我们目前单机只启动了 1 个哨兵，所以只要这 1 个哨兵认定主机死了，就可以直接判定【客观下线】并去换老大（在生产环境有 3 个哨兵时，这里通常写 2）。
sentinel down-after-milliseconds mymaster 5000：如果主机连续 5000毫秒（5秒） 不理哨兵的 PING，哨兵就判定它【主观下线】。
sentinel failover-timeout mymaster 15000：故障转移的超时时间设为 15 秒。

2. 启动哨兵进程

执行以下命令，把哨兵保安团派上岗：

bash 复制代码

redis-sentinel /etc/redis/sentinel.conf

检查三个进程是否全部合体：

输入 ps -ef | grep redis，此时你必须看到三个进程并存才算大功告成：

redis-server *:6379（主机）
redis-server *:6380（从机）
redis-sentinel *:26379（哨兵，你的新保安）

3. 见证奇迹------暴力干死主机，围观自动救场

现在，我们要扮演一回"断电事故"。直接用 pkill 精准干掉 6379 主机：

bash 复制代码

pkill -f "redis-server *:6379"

数 5 个数（因为我们配了 5 秒超时），然后立刻连入 6380 从机 去刺探情报，看看它有没有像你刚才说的那样，自己提升成了新主机：

bash 复制代码

redis-cli -p 6380 info replication

你会看到 6380 的状态已经悄悄发生了改变：

text 复制代码

# Replication
role:master           <─── 奇迹发生！6380 自动翻身农奴把歌唱，变成了 Master！
connected_slaves:0

4. 旧主机复活

我们现在把刚被打死的 6379 重新启动起来，看看它的下场：

bash 复制代码

redis-server --port 6379 --daemonize yes --bind 0.0.0.0 --protected-mode no --dir /var/lib/redis

启动后，给哨兵 2 秒钟的反应时间。然后再次进入 6380（新老大） 里看一眼：

bash 复制代码

redis-cli -p 6380 info replication

如下：

text 复制代码

role:master
connected_slaves:1    <─── 变回 1 了！
slave0:ip=127.0.0.1,port=6379,state=online... <─── 曾经威风凛凛的 6379，现在变成了 6380 的 Slave！

注意，这里的测试和实际的业务区别很大，主要有以下几个方面：

对比维度	🖥️ 虚拟机练习（开发/测试）	🏭 实际生产环境
部署架构	单机部署：所有Redis实例（主、从）和哨兵都在一台虚拟机，使用`127.0.0.1`通信。	跨节点高可用：哨兵节点数≥3且为奇数，每个哨兵部署在不同物理机或可用区。哨兵与Redis节点资源分离。
关键配置	基础配置（quorum=1, `down-after-milliseconds`=5秒）。无密码。	参数调优：`quorum`设为`N/2+1`（如3哨兵时设为2）。`down-after-milliseconds`默认30秒，避免网络抖动。`failover-timeout`设为180秒。`parallel-syncs`从1开始调优。高并发场景考虑`min-slaves-to-write`防脑裂。连接需密码认证。
安全性	无任何安全配置，仅限内网访问，适用于测试环境。	安全加固：配置`requirepass`和`masterauth`。启用TLS/SSL加密通信。使用防火墙或安全组严格控制访问。
监控与告警	手动`ps`或`redis-cli info`检查。	集成监控系统：接入Prometheus+Grafana。配置哨兵通知脚本实现事件告警。
高可用机制	最多几十秒。业务端需手动感知IP变更或刷新配置。	完善高可用：故障转移通常在30秒内完成。客户端通过哨兵动态获取主节点地址（服务发现），自动故障切换。
运维与演练	无需长期维护。可在测试环境演练。	长期运营：使用进程管理工具（如`systemd`）。必须在模拟生产环境进行充分的故障演练。
网络规划	单一主机，无复杂网络问题。	跨数据中心部署：哨兵节点分散部署，避免单点。若主从跨机房，使用`slave-priority`参数强制指定切换目标。
资源开销	占用忽略不计。	Sentinel官方描述为"轻量级架构"（单个Sentinel节点仅占用约10MB内存）。

三，分片集群

1.概念

1.1 基础理论

哨兵模式虽然完美，但它有一个致命的物理极限：

数据无法拆分（全量存储）：在哨兵模式下，主库和所有从库里存的数据都是一模一样的。如果你的主库内存是 64G，那么整套系统最多就只能存 64G 的数据。

遇到海量数据直接挤爆：当公司业务暴增，有 500G 甚至 2TB 的海量数据需要存进缓存时，单台服务器的内存根本买不起、也装不下。而且，所有的写流量都死死卡在唯一的一个 Master 上，写并发遇到了无法突破的瓶颈。

为了打破这个魔咒，官方推出了 Redis Cluster（分片集群）。它的核心思想是：人多力量大，把数据拆散，分给多组"一主一从"一起存！

那么分片集群是怎么做到把数据均匀拆分到不同机器上的？

实际上这里使用了一个非常精妙的数学模型。

redis cluster规定，整个集群的虚拟空间被划分成了16384个萝卜坑，官方管它们叫哈希槽。

逻辑编号从0一直到16383.

假设我们部署了一个由3台主库组成的集群，这16384个槽会被平分给这三台机器。

MasterA：负责0到5460，依次类推。

当客户端发来一个请求比如说set name g 时，redis怎么知道该把这个name给谁呢？

现在底层会执行一个这种公式：

S l o t = C R C 16 ( k e y ) ( m o d 16384 ) Slot = CRC16(key) \pmod{16384} Slot=CRC16(key)(mod16384)

redis会先对这个key利用crc16算法算出一个超级大的整数。

然后拿这个整数对16384取余。

如果算出来的数是6000，6000属于B，所以就被存到B中去了。

如果要get name，同样经历一轮这种运算，就会直接到B中去取。

这就做到了多台机器协同，内存容量和并发瞬间翻了三倍，而且还能扩容。

不过实际生产环境，受心跳，网络，故障等影响，建议主库小于1000。如果还有更多，比如说比16384还要大，那么原生的redis cluster就不支持了，因为每个主库至少要有一个槽。

要支撑更多的分片，应该用其它的分布式方案。

1.2 MOVED重定向机制

在前面的主从或者哨兵模式下，客户端连上一台机器，就能顺藤摸瓜拿到所有数据。

但是在分片集群中，情况变了。数据被拆分成16384个槽分给了不同的Master。

假设我们现在有三台主机A，B，C。

现在，我们并不知道某一个具体的key在谁手里。客户端可能随机挑了一个主机连接，并尝试读取key。

接下来就会触发Redis Cluster的经典重定向流程。

暗中计算：Node A 收到客户端的 GET name 请求后，在自己的底层也执行了那套公式： S l o t = C R C 16 ( " n a m e " ) ( m o d 16384 ) Slot = CRC16("name") \pmod{16384} Slot=CRC16("name")(mod16384)。
算出来的结果是 6000。Node A 一看自己的账本："我这里只管 0 到 5460 号槽，6000 号槽在隔壁 Node B 那里呢！"
Node A 绝对不会帮客户端去隔壁借数据，而是直接报错(error) MOVED 6000 192.168.1.11:6379，意思是6000并不在我这，并告知6000在哪台主机上。
客户端收到这个报错后，会自动断开与 Node A 的连接，转身去连接 Node B，重新发送 GET name，这才把数据成功拿出来。

1.3 去中心化

看完上面的重定向机制，你可能会觉得这种连来连去效率太低了。

这就不得不提到 Redis Cluster 的另一个伟大设计：去中心化（Peer-to-Peer）。

在很多分布式架构里，都有一个"总司令"（比如 HDFS 里的 NameNode，或者其他的 Master 节点），它专门用来记录所有数据的存放位置。每次客户端查数据，都得先去问一遍"总司令"，然后再去找干活的小弟。

缺点：一旦"总司令"累死了（宕机），整个庞大的集群就彻底瘫痪了。

而 Redis Cluster 没有任何总指挥官！

每一个 Redis 节点在启动并加入集群后，它们之间会通过一种叫 Gossip（八卦协议）的网络管道，疯狂地在后台聊天、交换情报。
每一个节点手里，都握有一张全网最完整的"槽位路由表"。Node A 知道 B 管哪些槽，B 也知道 C 管哪些槽。
对于客户端（驱动程序）来说：现在的 Java / Go 语言的 Redis 客户端（如 Jedis、Lettuce）都非常聪明。它们在第一次连接集群时，就会把全网的"槽位路由表"偷偷下载并缓存到本地内存里。

所以，在实际开发中，代码只有在第一次访问或者集群扩容调整槽位时，才会偶尔触发一次 MOVED 重定向。在绝大多数日常运行中，客户端在本地就能瞬间算出该找谁，然后直奔主题，精准一击。

1.4 关于两个细节

为什么刚好是 16384（ 2 14 2^{14} 214）个槽，而不是 65536（ 2 16 2^{16} 216）？

节省网络带宽：Redis 节点之间需要频繁交互，心跳包里必须带上自己负责的槽位图（Bitmap）。如果是 16384 个槽，这张图只需要 2KB 的空间；如果是 65536 个槽，就需要 8KB。对于每秒都在频繁交互的集群来说，这会极大地浪费宝贵的网络带宽。

集群规模上限：官方认为 Redis Cluster 的集群节点不太可能超过 1000 个。对于 1000 个以内的节点，16384 个槽位已经足够让数据分布得非常均匀了，没必要用更大的数字。

槽和 Key 的解耦：Hash Tag

有时候我们希望两个完全不同的 Key（比如 user:100:name 和 user:100:age）必须存放在同一台机器上，因为后面要用事务一次性操作它们。

解法：用大括号 {}。只要 Key 里包含了大括号，Redis 就只会对大括号里面的内容进行哈希计算。也就是说，{user:100}:name 和 {user:100}:age 算出来的槽位绝对一模一样，它们会被雷打不动地分到同一个 Master 里。

2.关于在虚拟机中单机部署模拟集群架构

第一步是批量创建 6 个独立节点的配置文件。由于节点较多，我们直接使用 Linux 的 for 循环命令，在 root 用户下执行以下这段神级组合拳，它会一次性在 /etc/redis/ 目录下自动生成 redis_7001.conf 到 redis_7006.conf 这 6 个纯净版配置文件，并自动为每个实例创建专属的数据目录：

bash 复制代码

for port in {7001..7006}; do
mkdir -p /var/lib/redis_${port}
cat << EOF > /etc/redis/redis_${port}.conf
port ${port}
daemonize yes
bind 0.0.0.0
protected-mode no
dir /var/lib/redis_${port}
appendonly yes
appendfsync everysec
cluster-enabled yes
cluster-config-file nodes_${port}.conf
cluster-node-timeout 5000
EOF
done

这段配置中，前几行和之前的单机配置一样，让 6 个进程各过各的、在后台静默运行。而最灵魂的是最后三行：cluster-enabled yes 明确告诉 Redis 开启分片集群模式；cluster-config-file 让它在运行期间自动记录并维护一份集群的槽位和节点状态表；cluster-node-timeout 设置了节点间通信的断线超时时间为 5 秒。

第二步是批量启动这 6 个实例并一键握手组网。配置文件生成后，首先在终端执行循环命令把 6 个 Redis 进程全部在后台轰起来：for port in {7001..7006}; do redis-server /etc/redis/redis_${port}.conf; done，启动后可输入 ps -ef | grep redis 确保 7001 到 7006 全部在跑；接下来执行 Redis 官方的一键组网神令，把这 6 个孤立的节点连接成一个有机的联邦，并在其中自动划分好 3 主 3 从的身份：

bash 复制代码

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1

命令最后的 --cluster-replicas 1 意思是"为每个主节点配备 1 个从节点"。

输入命令后，终端会打印出虚拟槽位的划分预案，并弹出一个提示询问 Can I set the above configuration? (type 'yes' to accept):，此时毫不犹豫地输入 yes 并回车。

稍等片刻，当你看到终端刷出 [OK] All 16384 slots covered. 时，恭喜你，你人生中第一套真正的分布式高可用分片集群便彻底宣告诞生！

你可以通过输入命令 redis-cli -c -p 7001 进入集群模式的客户端（注意一定要带上 -c 参数），随意执行一下 SET school gemini，你就会在黑窗口里亲眼目睹它由于计算了哈希槽，瞬间把你自动重定向跳转到了其他端口，体验到"去中心化"路由的绝对震撼。

以后在生产环境中，与这里最大的不同依然在于"物理网卡的隔离"和"灾难容错的极限规划"：

我们在本地虚拟机里组网时，IP 全部无脑写的是 127.0.0.1 环回地址，导致 6 个节点共用同一块虚拟网卡、同一块硬盘和同一个 CPU；

但在真正的生产环境中，这 6 个实例会被严格拆散部署在 6 台（或者至少 3 台，每台部署一主一从）独立的物理服务器上，组网命令里的 IP 必须全部替换为企业内网的真实局域网 IP（如 192.168.1.x），这样做的核心目的就是为了实现物理级别的"防碎裂容灾"------当机房里某一台服务器突然遭遇主板烧毁或拉闸断电时，其他服务器上的从节点和哨兵集群能在瞬间接管断裂的哈希槽，保证整个公司的核心缓存业务在硬件毁灭时依然稳如泰山。