Redis 哨兵（Sentinel）详解：原理、选举机制与实战部署

时间的拾荒人2026-11-15 9:25

🪖 哨兵

🖥️ 问题导入

Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）来解决这个问题。

📑 目录

  • [1. 基本概念](#1. 基本概念)
  • [2. 主从复制问题](#2. 主从复制问题)
  • [3. 手动恢复主节点故障](#3. 手动恢复主节点故障)
  • [4. 哨兵自动恢复主节点故障](#4. 哨兵自动恢复主节点故障)
  • [5. 安装部署 - 实战](#5. 安装部署 - 实战)
    • [5.1 准备工作](#5.1 准备工作)
    • [5.2 编排 Redis 主从节点](#5.2 编排 Redis 主从节点)
    • [5.3 编排 redis-sentinel 节点](#5.3 编排 redis-sentinel 节点)
  • [6. 主观下线和客观下线](#6. 主观下线和客观下线)
  • [7. 选举原理](#7. 选举原理)
    • [7.1 主观下线](#7.1 主观下线)
    • [7.2 客观下线](#7.2 客观下线)
    • [7.3 选出 leader 哨兵](#7.3 选出 leader 哨兵)
    • [7.4 leader 挑选出合适的 slave 成为新的 master](#7.4 leader 挑选出合适的 slave 成为新的 master)
  • [8. 小结](#8. 小结)
  • [9. 经典面试题](#9. 经典面试题)

。

✅️ 1. 基本概念

Redis Sentinel 基本名词解释如下：

名词 逻辑结构 物理结构
主节点 Redis 主服务 一个独立的 redis-server 进程
从节点 Redis 从服务 一个独立的 redis-server 进程
Redis 数据节点 主从节点 主节点和从节点的进程
哨兵节点 监控 Redis 数据节点的节点 一个独立的 redis-sentinel 进程
哨兵节点集合 若干哨兵节点的抽象组合 若干 redis-sentinel 进程
Redis 哨兵（Sentinel） Redis 提供的高可用方案 哨兵节点集合和 Redis 主从节点
应用方 泛指一个或多个客户端 一个或多个连接 Redis 的进程

💡 Redis Sentinel 是 Redis 的⾼可⽤实现⽅案，在实际的⽣产环境中，对提⾼整个系统的⾼可⽤是⾮常有帮助的

✅️ 2. 主从复制问题

Redis 的主从复制模式 可以将主节点的数据改变同步到从节点，这样从节点就可以起到两个作⽤：

第⼀，作为主节点的⼀个备份，⼀旦主节点出了故障无法访问，从节点可以作为后备 "顶" 上来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性）。

第⼆，从节点可以分担主节点上的读压⼒，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。但是主从复制模式并不是万能的，它同样遗留下以下⼏个问题：

  • 主节点发⽣故障时，主从节点切换过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间具有不确定性。
  • 主节点可以将读压⼒分散出去，但写压⼒/存储压⼒是⽆法被分担的，还是受到单机的限制。

其中第⼀个问题是⾼可⽤问题，即 Redis 哨兵主要解决的问题。

第⼆个问题是属于存储分布式的问题，留给Redis集群去解决。

✅️ 3. 手动恢复主节点故障
✅️ 4. 哨兵自动恢复主节点故障

当主节点出现故障时，Redis Sentinel 能⾃动完成故障发现和故障转移 ，并通知应⽤⽅，从⽽实现真正的⾼可⽤。

Redis Sentinel 是⼀个分布式架构，其中包含若⼲个 Sentinel 节点和 Redis 数据节点，每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控，当它发现节点不可达时，会对节点做下线表⽰。如果下线的是主节点，它还会和其他的 Sentinel 节点进⾏ "协商"，当⼤多数Sentinel节点对主节点不可达这个结论达成共识之后，它们会在内部 "选举" 出⼀个领导节点来完成⾃动故障转移的⼯作，同时将这个变化实时通知给 Redis 应⽤⽅。整个过程是完全⾃动的，不需要⼈⼯介⼊。

🍃 理解：第2步的目的主要是防⽌出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下。

通过上⾯的介绍，可以看出 Redis Sentinel 具有以下⼏个功能：

  • 监控: Sentinel 节点会定期检测Redis 数据节点、其余哨兵节点是否可达。
  • 故障转移: 实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
  • 通知: Sentinel 节点会将故障转移的结果通知给应⽤⽅。

🔝拓展：分布式系统的基本原则：在分布式系统中，应该避免使用"单点".
❓ 为什么Redis中使用的哨兵个数推荐使用奇数个？

Redis Sentinel 通常部署 3、5、7 个哨兵节点 ，主要是因为哨兵的Leader选举采用多数派投票机制 。使用奇数个节点，可以在保证容错能力的同时减少资源浪费。

多数派投票机制

当 Redis 主节点发生故障时，哨兵需要选举出一个 Leader，由它负责执行故障转移。

Leader 必须获得超过半数哨兵的选票 才能当选。

为什么推荐奇数个？

哨兵数量 多数派票数 最多容忍故障数
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3

可以发现：

  • 3 个和4个哨兵 ：都最多容忍 1 个节点故障。
  • 5 个和 6 个哨兵 ：都最多容忍2个节点故障。
  • 7 个哨兵 ：最多容忍3个节点故障。
    因此，增加一个哨兵使节点总数从奇数变为偶数，并不会提升多数派选举的容错能力，反而增加了资源销。

❓️ 为什么不使用单个哨兵？

虽然单个哨兵也可以工作，但存在以下问题：

  • 单点故障风险：唯一的哨兵发生故障后，无法继续执行自动故障转移。
  • 缺少交叉验证：无法通过多个哨兵共同确认主节点是否真正下线。

因此，生产环境中通常建议至少部署 3 个独立的哨兵实例 。

核心原因是：在多数派投票机制下，奇数个哨兵可以用更少的节点实现相同的选举容错能力，提高资源利用率。

✅️ 5. 安装部署 - 实战
5.1 准备工作

① 安装docker-compose

bash 复制代码 
# ubuntu
apt install docker-compose
# centos
yum install docker-compose

② 停止本地所有的redis-server

bash 复制代码 
# 停⽌ redis-server
service redis-server stop
# 停⽌ redis-sentinel 如果已经有的话. 
service redis-sentinel stop

③ 使用docker获取redis镜像

bash 复制代码 
docker pull redis:5.0.9
5.2 编排Redis主从节点

① 编写 docker-compose.yml，创建/root/redis/docker-compose.yml, 同时cd到yml所在⽬录中.

注意 : docker 中可以通过容器名字, 作为ip地址, 进⾏相互之间的访问.

bash 复制代码 
version: '3.7'
services:
   master:
    image: 'redis:5.0.9'
    container_name: redis-master
    restart: always
    command: redis-server --appendonly yes
    ports: 
     - 6379:6379
   slave1:
    image: 'redis:5.0.9'
    container_name: redis-slave1
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6380:6379
   slave2:
    image: 'redis:5.0.9'
    container_name: redis-slave2
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
     -6381:6379

② 启动三个容器(一个主节点，两个从节点)

bash 复制代码 
docker compose up -d

📌 注意：如果启动发现上一步的配置信息有误，需要重新操作，需要使用docker-compose down即可停止并删除刚才创建好的容器。

③ 查看运行日志

bash 复制代码 
docker compose logs

💡 提示：上述步骤均需要保证工作目录在yml的同级目录中，才能工作。

④ 验证主从节点启动情况

主节点

bash 复制代码 
# redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1
slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:348
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:348

从节点1

bash 复制代码 
# redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:446
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:446
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:446

从节点2

bash 复制代码 
# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:516
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:516
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:516
5.3 编排 redis-sentinel节点

📚说明 ：此处将redis-sentinel节点的编排文件和上面的redis主从节点编排文件分开，其目有如下两点：

  1. 日志分开记录，查看更加方便。
  2. 确保 redis 主从节点启动之后才启动 redis-sentinel. 如果先启动redis-sentinel的话, 可能触发额外的选举过程, 混淆视听. (不是说先启动哨兵不⾏, ⽽是观察的结果可能存在⼀定随机性)
    ✏️ 拓展

是否可以将6个容器，都写到一个配置文件中，一次就全部启动？

如果使用这个方案，由于docker-compose启动容器的顺序不确定，局部你保证redis-server一定是在哨兵之前启动的!!!最终结果也能正常运行，但是执行的日志可能会有变数。因此分成两组来启动，就可以保证上述顺序，观察到的日志，比较可控。

① 创建docker-compose.yml文件

创建/root/redis-sentinel/docker-compose.yml,同时切换到yml所在目录。

bash 复制代码 
version: '3.7'
services:
	sentinel1:
		image: 'redis:5.0.9'//镜像
		container_name: redis-sentinel-1//镜像名字
		restart: always//自动启动
		command: redis-sentinel /etc/redis/sentinel.conf
		volumes:
		  - ./sentinel1.conf:/etc/redis/sentinel.conf
		ports:
		  - 26379:26379
 sentinel2:
	 image: 'redis:5.0.9'
	 container_name: redis-sentinel-2
	 restart: always
	 command: redis-sentinel /etc/redis/sentinel.conf
	 volumes:
	 	- ./sentinel2.conf:/etc/redis/sentinel.conf
	 ports:
	 	- 26380:26379
 sentinel3:
	 image: 'redis:5.0.9'
	 container_name: redis-sentinel-3
	 restart: always
	 command: redis-sentinel /etc/redis/sentinel.conf
	 volumes:
	 	- ./sentinel3.conf:/etc/redis/sentinel.conf
	 ports:
	 	- 26381:26379
networks:
 default:
	 external:
		 name: redis-data_default

📌 说明

2docker的一个核心功能，能够进行端口的映射，容器内部乐意使用啥端口都行，映射出去以后，还是需要确保端口不能重复(如26381:26379)。
❓️哨兵节点会在运行过程中，对配置文件进行自动修改。因此，就不能拿一个配置文件，给三个容器分别映射。

② 创建配置文件

创建 sentinel1.conf sentinel2.conf sentinel3.conf . 三份⽂件的内容是完全相同的.都放到 /root/redis-sentinel/ ⽬录中.

bash 复制代码 
bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

🐱 理解

sentinel monitor 主节点 主节点ip 主节点端口 法定票数

  1. 主节点名, 这个是哨兵内部⾃⼰起的名字.
  2. 主节点 ip, 部署 redis-master 的设备 ip. 此处由于是使⽤ docker, 可以直接写docker的容器名, 会被⾃动 DNS 成对应的容器 ip
  3. 主节点端⼝,.
  4. 法定票数, 哨兵需要判定主节点是否挂了. 但是有的时候可能因为特殊情况, ⽐如主节点仍然⼯作正常, 但是哨兵节点⾃⼰⽹络出问题了, ⽆法访问到主节点了. 此时就可能会使该哨兵节点认为主节点下线, 出现误判. 使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法. 需要多个哨兵都认为主节点挂了, 票数 >= 法定票数 之后, 才会真的认为主节点是挂了.

sentinel down-after-milliseconds

  1. 主节点和哨兵之间通过⼼跳包来进⾏沟通. 如果⼼跳包在指定的时间内还没回来, 就视为是节点出现故障.此处的单位是毫秒。
    拓展 ：既然内容相同, 为啥要创建多份配置⽂件?

redis-sentinel 在运⾏中可能会对配置进⾏ rewrite, 修改⽂件内容. 如果⽤⼀份⽂件, 就可能出现修改混乱的情况.

③ 启动容器和查看日志

bash 复制代码 
docker compose up -d
docker compose logs

④ 查看redis-sentinel 的配置rewrite现象

bash 复制代码 
bind 0.0.0.0
port 26379
sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aa
sentinel deny-scripts-reconfig yes
# Generated by CONFIG REWRITE
dir "/data"
sentinel monitor redis-master 172.22.0.4 6379 2
sentinel down-after-milliseconds redis-master 1000
sentinel config-epoch redis-master 1
sentinel leader-epoch redis-master 1
sentinel known-replica redis-master 172.22.0.2 6379
sentinel known-replica redis-master 172.22.0.3 6379
sentinel known-sentinel redis-master 172.22.0.7 26379 
f718caed536d178f5ea6d1316d09407cfae43dd2
sentinel known-sentinel redis-master 172.22.0.5 26379 
2ab6de82279bb77f8397c309d36238f51273e80a
sentinel current-epoch 1

📌 声明

# Generated by CONFIG REWRITE 这⾥的内容就是⾃动修改的.对⽐这三份⽂件, 可以看到配置内容是存在差异的.

✅️ 6. 主观下线和客观下线

主节点 redis-master 宕机之后

此处为了演示，使用命令docker stop redis-master 来模拟服务器下线。如下是哨兵的日志：

可以看到哨兵发现了主节点 sdown, 进⼀步的由于主节点宕机得票达到 3/2 , 达到法定得票, 于是master 被判定为 odown.此时哨兵从从节点中挑选了一个新的master ,如：172.22.04:6379 这个节点.具体见上图第二个红框。此时的redis是可以正常使用的。

🦒 解释

主观下线 (Subjectively Down, SDown): 哨兵感知到主节点没⼼跳了. 判定为主观下线.

客观下线 (Objectively Down, ODown): 多个哨兵达成⼀致意⻅, 才能认为 master 确实下线了.

redis-master 重启之后

此时手动使用命令 docker start redis-master 将主节点进行重启。此时查看哨兵日志可见刚才的新主节点变成了从节点slave.

📚 结论

Redis 主节点如果宕机, 哨兵会把其中的⼀个从节点, 提拔成主节点.

当之前的 Redis 主节点重启之后, 这个主节点被加⼊到哨兵的监控中, 但是只会被作为从节点使⽤.

✅️ 7. 选举原理
7.1 主观下线

当redis-master宕机，此时的redis -master 和三个哨兵之间的心跳包就没有了。此时，从三个哨兵的角度来看，redis-master出现了严重故障。因此三个 哨兵均会把redis-master节点判定为主观下线(sDown)。

7.2 客观下线

此时，三个哨兵均会对redis-master主节点故障这件事进行投票，当票数 >= 配置的法定票数后，上述配置的法定票数是2票。此时就意味着redis-master确实是发生了故障，不是虚假故障，此时触发客观下线(ODown)。

7.3 选出leader哨兵

接下来需要哨兵从剩余的 slave 中挑选出⼀个新的 master. 这个⼯作不需要所有的哨兵都参与. 只需要选出个代表 (称为 leader), 由 leader 负责进⾏slave升级到master的提拔过程.

这个选举的过程涉及到 Raft 算法:

🧸 Raft算法

假定⼀共三个哨兵节点：S1, S2, S3

  1. 每个哨兵节点都给其他所有哨兵节点, 发起⼀个 "拉票请求". (S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3,S3 -> S1, S3 - S2)
  2. 收到拉票请求的节点, 会回复⼀个 "投票响应". 响应的结果有两种可能, 投or不投.
    ⽐如 S1 给 S2 发了个投票请求, S2 就会给 S1 返回投票响应.
    到底 S2 是否要投 S1 呢? 取决于 S2 是否给别⼈投过票了. (每个哨兵只有⼀票).
    如果 S2 没有给别⼈投过票, 换⽽⾔之, S1 是第⼀个向S2拉票的, 那么 S2 就会投 S1. 否则则不投.
  3. ⼀轮投票完成之后, 发现得票超过半数的节点, ⾃动成为 leader.
    如果出现平票的情况 (S1 投 S2, S2投 S, S3 投 S1, 每⼈⼀票), 就重新再投⼀次即可.这也是为啥建议哨兵节点设置成奇数个的原因. 如果是偶数个, 则增⼤了平票的概率, 带来不必要的开销.
  4. leader节点负责挑选⼀个slave成为新的 master. 当其他的sentenal发现新的master 出现了, 就说明选举结束了.

简⽽⾔之, Raft 算法的核⼼就是 "先下⼿为强". 谁率先发出了拉票请求, 谁就有更⼤的概率成为 leader.

此处的选举结果的决定性因素是 "网络延时",网络延时具有一定的随机性，具体选哪一个哨兵节点作为leader节点不重要，只要选出一个leader节点即可。

7.4 leader 挑选出合适的 slave 成为新的 master

挑选规则:

  1. ⽐较优先级. 优先级⾼(数值⼩的)的上位. 优先级是配置⽂件中的配置项( slave-priority 或者replica-priority ).
  2. ⽐较 replication offset 谁复制的数据多, ⾼的上位.
  3. ⽐较 run id , 谁的id⼩, 谁上位.

当某个 slave 节点被指定为 master 之后:

  1. leader 指定该节点执⾏ slave no one , 成为 master
  2. leader 指定剩余的 slave 节点, 都依附于这个新 master

📌 注意

  1. 哨兵节点不能只有⼀个. 否则哨兵节点挂了也会影响系统可⽤性.
  2. 哨兵节点最好是奇数个. ⽅便选举 leader, 得票更容易超过半数.大部分情况3个哨兵足够了。
  3. 哨兵节点不负责存储数据. 仍然是 redis 主从节点负责存储.哨兵节点就可以使用一些配置不高的机器来部署
  4. 哨兵 + 主从复制解决的问题是 "提⾼可⽤性", 不能解决 "数据极端情况下写丢失" 的问题.
  5. 哨兵 + 主从复制不能提⾼数据的存储容量. 当我们需要存的数据接近或者超过机器的物理内存, 这样的结构就难以胜任了.
✅️ 8. 小结

本节围绕 Redis Sentinel（哨兵） 展开，从「为什么需要哨兵」到「哨兵如何完成自动故障转移」做了完整梳理，核心要点如下：

  • 问题背景 ：Redis 主从复制解决了数据备份与读压力分担，但主节点故障时仍需人工切换，故障恢复时间不可控，这正是哨兵要解决的高可用问题。
  • 核心能力 ：哨兵具备监控 、故障转移 、通知三大功能，能在主节点故障时自动完成故障发现与主从切换，并把结果通知给应用方。
  • 关键概念 ：主观下线（SDown）是单个哨兵判定节点不可达；客观下线（ODown）是多个哨兵投票达成共识，票数达到法定票数后才确认主节点真的下线。
  • 选举流程 ：先由哨兵通过 Raft 算法选出 leader 哨兵，再由 leader 按「优先级 → 复制偏移量 → run id」的规则挑选合适的从节点晋升为新主节点。
  • 部署建议 ：哨兵节点至少 3 个且推荐奇数个，既避免单点故障，又能在多数派投票机制下用更少节点获得相同的容错能力。
  • 能力边界 ：哨兵 + 主从复制提升的是可用性 ，既不能解决极端情况下的写丢失，也不能提升数据的存储容量------后者需要 Redis Cluster 来解决。

一句话总结：哨兵让 Redis 主从架构从「人工运维」走向「自动容灾」，但它只负责高可用，不负责数据分片。

✅️ 9. 经典面试题

Q1：Redis Sentinel 的作用是什么？它解决了主从复制的什么问题？

Redis Sentinel 是 Redis 官方提供的高可用方案。主从复制模式下，主节点故障需要人工切换，恢复时间不确定；哨兵通过监控、故障转移、通知三大能力，实现主节点故障的自动发现与自动切换，从而提升系统可用性。注意它只解决高可用问题，不解决写压力与存储容量问题。

Q2：主观下线（SDown）和客观下线（ODown）有什么区别？

  • 主观下线 ：单个哨兵在 down-after-milliseconds 时间内没收到主节点心跳，就单方面认为主节点下线。此时可能只是该哨兵自身网络异常，存在误判风险。
  • 客观下线 ：该哨兵向其他哨兵「求证」，当认为主节点下线的票数 >= 配置的法定票数（quorum）时，才判定主节点真正下线。

一句话：主观下线是「我认为」，客观下线是「大家公认」。

Q3：哨兵是如何选出 leader 的？

采用 Raft 算法的思想：每个哨兵向其他哨兵发起拉票请求，收到请求的哨兵若本轮尚未投票则投出自己的一票（每个哨兵只有一票）；一轮投票后得票超过半数的节点自动成为 leader。若出现平票则重新投票。核心是「先下手为强」，谁先发出拉票请求谁更容易当选，因此结果受网络延时影响，但选出谁并不重要，只要选出一个即可。

Q4：leader 哨兵如何挑选新的主节点？

按以下顺序依次比较：

  1. 优先级 ：replica-priority（旧版本为 slave-priority）数值越小优先级越高；
  2. 复制偏移量 ：replication offset 越大，说明数据越新，优先上位；
  3. run id ：若前两项相同，则 run id 较小的节点上位。

选定后，leader 让该节点执行 slaveof no one 成为新主节点，并让其余从节点依附于新主节点。

Q5：为什么推荐部署奇数个哨兵节点？

因为 leader 选举采用多数派投票机制，需要超过半数选票才能当选。对比可知：3 个和 4 个哨兵都最多容忍 1 个节点故障，5 个和 6 个都最多容忍 2 个。从奇数增加到偶数并不能提升容错能力，反而增加资源开销和平票概率，所以推荐 3、5、7 这样的奇数个。

Q6：为什么不能只部署一个哨兵？

单个哨兵存在两个问题：一是单点故障 ，哨兵自身挂掉后自动故障转移就彻底失效；二是缺少交叉验证 ，无法通过多个哨兵共同确认主节点是否真的下线，容易误判。因此生产环境建议至少部署 3 个独立哨兵实例。

Q7：哨兵节点重启后，原来的主节点会怎样？

原主节点重启后会被哨兵重新纳入监控，但此时它只会被当作从节点使用，依附于故障转移后产生的新主节点，而不会自动恢复为主节点身份。

Q8：哨兵 + 主从复制能解决数据容量不足的问题吗？

不能。哨兵 + 主从复制提升的是可用性 ，所有节点存储的仍是全量数据，写压力和存储容量依旧受单机限制。当数据量接近或超过单机物理内存时，需要使用 Redis Cluster 做数据分片。

相关推荐
黄连木笛14 分钟前
Redis Insight 汉化教程：Windows / macOS / Linux 设置中文界面（附繁體、教程汉化、关闭自动更新）
数据库·redis·缓存
nice_lcj52019 分钟前
MySQL 存储引擎入门：InnoDB 和 MyISAM 到底怎么选
java·数据库·mysql·面试·innodb·存储引擎·myisam
装不满的克莱因瓶1 小时前
设计模式之策略模式核心概念和应用场景
java·后端·设计模式·架构·系统架构·策略模式
真上帝的左手11 小时前
30. 技术专题-‌应用框架组件-分布式架构
分布式·架构·系统架构·分布式架构
时间的拾荒人13 小时前
Redis 主从复制详解：配置实操 + 原理机制
数据库·redis·面试
Decay__15 小时前
SQLServer 索引与 SQL 优化 —— 聚集索引、非聚集索引、覆盖索引、碎片维护与执行计划
运维·数据库·sql·mysql·架构
Dawson Zhu16 小时前
【分布式训练④】张量并行与序列并行：把单层参数切碎分到多张卡
人工智能·语言模型·架构·aigc·agi
码客-ygluu19 小时前
一个通用游戏数据服务器
c++·架构
炫酷的大高个21 小时前
98% 连跑 20 次只剩 67%，我算了大模型重试账
人工智能·架构·开源
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03几个好用的ip纯净度检测网站04微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新05GitHub 镜像站点06如何新建文件夹？ 电脑新建文件夹的4种方法07蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接08苹果iPA游戏软件资源下载网站09昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战10Dify：一站式AI应用开发平台全解析与Windows部署指南