1.超详细Redis7.X 安装教程

CoolTiger、2026-07-02 8:03

超详细Redis7.X 安装教程

    • [📋 知识体系总览](#📋 知识体系总览)
    • [一、Redis 单机部署](#一、Redis 单机部署)
      • [✅1. 检查安装 gcc 环境](#✅1. 检查安装 gcc 环境)
      • [✅2. 下载安装 Redis](#✅2. 下载安装 Redis)
      • [✅3. 启动 Redis](#✅3. 启动 Redis)
      • [✅4. 配置 Redis](#✅4. 配置 Redis)
      • [✅5. 退出 / 关闭 Redis](#✅5. 退出 / 关闭 Redis)
    • [二、主从部署（Master-Slave Replication）](#二、主从部署（Master-Slave Replication）)
      • [✅1. 主从复制的作用](#✅1. 主从复制的作用)
      • [✅2. 主从复制部署](#✅2. 主从复制部署)
      • [✅3. 主从复制缺点](#✅3. 主从复制缺点)
    • 三、哨兵部署（Sentinel）
      • [✅1. 哨兵模式的原理](#✅1. 哨兵模式的原理)
      • [✅2. 哨兵选举与故障转移流程](#✅2. 哨兵选举与故障转移流程)
      • [✅3. 客观下线机制](#✅3. 客观下线机制)
      • [✅4. 哨兵模式部署](#✅4. 哨兵模式部署)
      • [✅5. 哨兵使用建议](#✅5. 哨兵使用建议)
      • [✅6. 哨兵模式：并不能保证数据零丢失](#✅6. 哨兵模式：并不能保证数据零丢失)
    • 四、集群部署（Cluster）
      • [✅1. Redis 集群的作用](#✅1. Redis 集群的作用)
      • [✅2. Redis 集群的数据分片（哈希槽）](#✅2. Redis 集群的数据分片（哈希槽）)
      • [✅3. 集群环境搭建](#✅3. 集群环境搭建)
      • [✅4. 集群数据读写](#✅4. 集群数据读写)
      • [✅5. 模拟故障转移](#✅5. 模拟故障转移)
    • 五、附录：完整配置文件与命令汇总
    • [📋 全文总结](#📋 全文总结)
      • [✅1. 四种部署模式对比](#✅1. 四种部署模式对比)
      • [✅2. 关键演进路径](#✅2. 关键演进路径)
      • [✅3. 面试核心要点](#✅3. 面试核心要点)

📋 知识体系总览

复制代码 
超详细Redis7.X 安装教程
├── 一、Redis 单机部署
│   ├── ✅1. 检查安装 gcc 环境
│   ├── ✅2. 下载安装 Redis
│   ├── ✅3. 启动 Redis
│   ├── ✅4. 配置 Redis
│   └── ✅5. 退出/关闭 Redis
├── 二、主从部署（Master-Slave Replication）
│   ├── ✅1. 主从复制的作用
│   ├── ✅2. 主从复制部署
│   └── ✅3. 主从复制缺点
├── 三、哨兵部署（Sentinel）
│   ├── ✅1. 哨兵模式的原理
│   ├── ✅2. 哨兵选举与故障转移流程
│   ├── ✅3. 客观下线机制
│   ├── ✅4. 哨兵模式部署
│   ├── ✅5. 哨兵使用建议
│   └── ✅6. 哨兵模式的数据丢失风险
├── 四、集群部署（Cluster）
│   ├── ✅1. Redis集群的作用
│   ├── ✅2. Redis集群的数据分片（哈希槽）
│   ├── ✅3. 集群环境搭建
│   ├── ✅4. 集群数据读写
│   └── ✅5. 模拟故障转移
└── 五、附录：完整配置文件与命令汇总
    ├── ✅1. 文件目录结构
    ├── ✅2. 各模式配置文件
    └── ✅3. 完整操作命令汇总

📝 核心： 本教程演示在 Linux 环境下安装 Redis7，涵盖单机部署、主从部署、哨兵部署、集群部署四种模式的安装以及相应的架构介绍。Redis 由 C 语言编写，运行需要 C 环境，因此需要先安装 gcc。

一、Redis 单机部署

✅1. 检查安装 gcc 环境

bash 复制代码 
# 关闭防火墙
systemctl stop firewalld.service

# 查看防火墙状态
firewall-cmd --state

# 卸载防火墙
yum remove firewalld

# 检查 gcc 版本
gcc --version

# 安装 gcc
yum install gcc

✅2. 下载安装 Redis

bash 复制代码 
# 安装应用养成良好习惯，文件归类
mkdir -p /opt/software/redis

# 进入 redis 文件夹，使用 wget 下载
cd /opt/software/redis
wget https://download.redis.io/redis-stable.tar.gz

# 解压下载的 redis 包
tar -xzf redis-stable.tar.gz

# 进入 redis-stable 目录，然后使用 make install 编译并安装
# 安装完成后 /usr/local/bin 会生成相应的服务
cd redis-stable
make install

# 检查是否成功生成
ll /usr/local/bin

编译安装后在 /usr/local/bin 下生成的可执行文件：

文件 说明
redis-benchmark 性能测试工具
redis-check-aof 修复有问题的 AOF 文件
redis-check-rdb 修复有问题的 RDB 文件
redis-sentinel Redis 哨兵集群使用
redis-server Redis 服务器启动命令
redis-cli 客户端，操作入口

✅3. 启动 Redis

有两种启动方式：

bash 复制代码 
# 方式一：Redis 源码路径下启动
./src/redis-server

# 方式二：使用 /usr/local/bin 路径下启动
redis-server

📝 注意： 前面的启动方式无法在后台运行，退出终端之后直接关闭了 Redis 服务，所以还需要针对 Redis 做一些配置。

✅4. 配置 Redis

修改当前 Redis 目录下的 redis.conf 文件：

bash 复制代码 
vim redis.conf

如果使用 vim 打开后没有行号，可以在打开 vim 后输入 :set number

需要修改的关键配置项：

配置项 行号 说明
bind * -::* #87 修改 bind 项，* -::* 支持远程连接
daemonize yes #309 开启守护进程，后台运行
logfile /opt/software/redis/redis-stable/redis.log #355 指定日志文件目录
dir /opt/software/redis #510 指定工作目录
requirepass 1qaz@WSX #1044 给默认用户设置密码，使用 redis-cli 连接时需要密码校验
protected-mode no #111 允许远程连接（如果不设置密码必须将此设置关闭）

修改完成后，使用配置文件启动 Redis，并使用 redis-cli 连接测试：

bash 复制代码 
redis-server redis.conf
redis-cli
auth 1qaz@WSX

📝 要点： protected-mode no 允许远程连接；daemonize yes 开启后台守护进程模式；requirepass 设置认证密码。生产环境建议设置复杂密码。

✅5. 退出 / 关闭 Redis

bash 复制代码 
# 退出 redis 客户端
quit

# 关闭 redis 服务
redis-cli shutdown

二、主从部署（Master-Slave Replication）

📝 核心： 主从复制是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点（Master），后者称为从节点（Slave）。数据的复制是单向的，只能由主节点到从节点。默认情况下，每台 Redis 服务器都是主节点；一个主节点可以有多个从节点，但一个从节点只能有一个主节点。

✅1. 主从复制的作用

a）数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

b）故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

c）负载均衡： 在主从复制的基础上配合读写分离，由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。

d）高可用基石： 主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

✅2. 主从复制部署

主节点不需要做任何改变，从节点需要修改配置加上主节点信息：

bash 复制代码 
# 在从节点配置文件中添加主节点信息
replicaof 192.168.75.129 6379

配置完成后，可以在主库检查从节点信息：

bash 复制代码 
# 主节点查看从节点信息
info Replication

✅3. 主从复制缺点

  • 复制延时，信号衰减： 由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器上有一定的延迟。当系统很繁忙的时候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。
  • Master 挂了如何办？ 默认情况下，不会在 Slave 节点中自动重选一个 Master，每次都要人工干预。

📝 关键理解： Redis 的主从复制主要用于实现数据的冗余备份和读分担，并不是为了提供高可用性。因此在系统高可用方面，单纯的主从架构无法很好地保证整个系统高可用。

三、哨兵部署（Sentinel）

📝 核心： Redis 哨兵模式是通过在独立的哨兵节点上运行特定的哨兵进程来实现的。这些哨兵进程监控主从节点的状态，并在发现故障时自动完成故障发现和转移，并通知应用方，实现高可用性。

✅1. 哨兵模式的原理

每个在线的哨兵节点都可以成为领导者，选举过程如下：

  1. 每个哨兵节点会向其它哨兵发送 is-master-down-by-addr 命令，征求判断并要求将自己设置为领导者
  2. 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者
  3. 如果哨兵发现自己在选举的票数 大于等于 num(sentinels)/2+1 时，将成为领导者；如果没有超过，继续选举

✅2. 哨兵选举与故障转移流程

监控主从节点：

  • 哨兵节点通过发送命令周期性地检查主从节点的健康状态，包括主节点是否在线、从节点是否同步等
  • 如果哨兵节点发现主节点不可用，它会触发一次故障转移

故障转移过程：

  1. 确认主节点： Sentinel 节点定期监控发现主节点是否出现故障。Sentinel 会向 Master 发送心跳 PING 来确认 Master 是否存活，如果 Master 在"一定时间范围"内不回应 PONG 或者是回复了一个错误消息，那么这个 Sentinel 会主观地（单方面地）认为这个 Master 已经不可用了

  2. 选举新主节点：

    • 过滤掉不健康的（下线或断线）、没有回复过哨兵 PING 响应的从节点
    • 选择从节点优先级最高的
    • 选择复制偏移量最大（复制最完整）的从节点
    • 当主节点出现故障，由领导者负责处理主节点的故障转移

  3. 客户端重定向： 哨兵节点会通知客户端新的主节点的位置，使其能够与新的主节点建立连接并发送请求。这确保了客户端可以无缝切换到新的主节点，继续进行操作。

此外，哨兵节点还负责监控从节点的状态。如果从节点出现故障，哨兵节点可以将其下线，并在从节点恢复正常后重新将其加入集群。

✅3. 客观下线机制

当主观下线的节点是主节点时，此时该哨兵节点会通过指令 sentinel is-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过 quorum（选举）个数时，哨兵节点则认为该主节点确实有问题，这样就客观下线了------大部分哨兵节点都同意下线操作，也就是客观下线。

✅4. 哨兵模式部署

3 个机器都需要修改 sentinel.conf 配置：

bash 复制代码 
protected-mode no                     # 第6行，关闭保护模式
daemonize yes                         # 第15行，指定 sentinel 为后台启动
logfile /opt/software/redis/redis-stable/sentinel.log  # 第34行，指定日志存放路径
dir /opt/software/redis               # 第73行，指定数据库存放路径
sentinel monitor mymaster 192.168.75.129 6379 2   # 第93行，指定监控的主节点
# 参数说明：mymaster 是主节点名称，192.168.75.129:6379 是主节点地址
# 最后的 2 表示：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000     # 第134行，判定服务器 down 的时间周期（默认30秒）
sentinel failover-timeout mymaster 180000           # 第234行，故障节点的最大超时时间（180秒）

配置完成之后先从主节点开始启动哨兵。启动后检查哨兵状态：

bash 复制代码 
redis-cli -p 26379 info sentinel

故障模拟：

bash 复制代码 
# 可以杀掉主节点的进程，也可以直接停掉主节点服务
ps aux | grep redis
redis-cli shutdown

# 观察哨兵日志，129 主节点下线，重新选举 131 为主节点
tail -f sentinel.log

# 重新启动 129 服务并观察日志，129 加入主从，此时主节点为 131 服务
redis-server redis.conf
tail -f sentinel.log

redis-cli -p 26379 info sentinel

# 观察哨兵日志
tail -f sentinel.log

# 停止哨兵
redis-cli -p 26379 shutdown

# 切换到 131 服务，已经为主节点
redis-cli info replication

当触发了哨兵选举之后，会在后台更改 redis.conf 与 sentinel.conf，可以检查每台机器的文件末尾的数据：

bash 复制代码 
cat redis.conf
cat sentinel.conf

✅5. 哨兵使用建议

  • 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
  • 哨兵节点数应该是奇数
  • 各个哨兵节点的配置应一致
  • 如果哨兵节点部署在 Docker 等容器里面，尤其要注意端口号的正确映射

✅6. 哨兵模式：并不能保证数据零丢失

1. 复制延迟： 在主从复制中，从节点的数据是异步复制自主节点的。这意味着在主节点故障时，从节点可能还没有完全同步最新的数据，从而导致数据丢失。

2. 故障检测和转移时间： Sentinel 检测到主节点故障并执行故障转移需要一定的时间。在这段时间内，主节点可能已经接收了一些写操作，但这些操作尚未被复制到从节点。

3. 网络分区： 在发生网络分区（网络分裂）的情况下，一部分节点可能与主节点失去联系。如果此时主节点继续处理写操作，那么在网络恢复之前，这些操作可能不会被复制到从节点。

4. 多个从节点同时故障： 如果所有的从节点同时故障或在故障转移之前与主节点失联，那么在主节点故障时，将没有可用的从节点来提升为主节点。

四、集群部署（Cluster）

📝 核心： Redis 集群是 Redis 的一种分布式运行模式，它通过分片（sharding）来提供数据的自动分区和管理，从而实现数据的高可用性和可扩展性。在集群模式下，数据被分割成多个部分（称为槽或 slots），分布在多个 Redis 节点上。集群中的节点分为主节点和从节点：主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。

✅1. Redis 集群的作用

数据分区（核心功能）：

  • 集群将数据分散到多个节点，突破了 Redis 单机内存大小的限制，存储容量大大增加
  • 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
  • Redis 单机内存大小受限问题：如果单机内存太大，bgsave 和 bgrewriteaof 的 fork 操作可能导致主进程阻塞；主从环境下主机切换时可能导致从节点长时间无法提供服务；全量复制阶段主节点的复制缓冲区可能溢出

高可用： 集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。

✅2. Redis 集群的数据分片（哈希槽）

Redis 集群引入了**哈希槽（hash slot）**的概念：

  • Redis 集群有 16384 个哈希槽（编号 0-16383）
  • 集群的每个节点负责一部分哈希槽
  • 每个 Key 通过 CRC16 校验后对 16384 取余来决定放置哪个哈希槽
  • 通过这个值，去找到对应的槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

以 3 个节点组成的集群为例：

  • 节点 A 包含 0 到 5460 号哈希槽
  • 节点 B 包含 5461 到 10922 号哈希槽
  • 节点 C 包含 10923 到 16383 号哈希槽

📝 关键理解： Redis 集群的主从复制模型中，如果节点 B 失败了，整个集群就会因缺少 5461-10922 这个范围的槽而不可用。因此需要为每个节点添加从节点 A1、B1、C1，在节点 B 失败后，集群选举 B1 为新的主节点继续服务。当 B 和 B1 都失败后，集群将不可用。

✅3. 集群环境搭建

Redis Cluster 被配置为三主三从模式。这意味着每台服务器上的两个 Redis 节点中，一个节点作为主库（master），另一个作为从库（slave）。

创建集群配置：

bash 复制代码 
# 创建集群配置文件夹，将下面的配置复制过去，另外两个机器重复这个过程
mkdir -p /opt/software/redis/redis-stable/cluster
mkdir -p /opt/software/redis/cluster
vim ./cluster/redis_6379.conf
vim ./cluster/redis_6380.conf

# 配置文件准备完成之后，启动所有 redis 服务，用 cluster 配置文件
redis-server ./cluster/redis_6379.conf
redis-server ./cluster/redis_6380.conf

# 检查服务
ps aux | grep redis

# 创建三主三从集群模式，每一个主节点带一个从节点
redis-cli --cluster create --cluster-replicas 1 \
  192.168.75.129:6379 192.168.75.129:6380 \
  192.168.75.131:6379 192.168.75.131:6380 \
  192.168.75.132:6379 192.168.75.132:6380

# 查看集群信息
redis-cli cluster info

# 查看单个节点信息
redis-cli info replication

# 查看集群节点身份信息
redis-cli cluster nodes

# 停止 redis 服务
redis-cli -p 6379 shutdown
redis-cli -p 6380 shutdown

6379 端口集群配置：

bash 复制代码 
# 允许所有的IP地址
bind * -::*
# 后台运行
daemonize yes
# 允许远程连接
protected-mode no
# 开启集群模式
cluster-enabled yes
# 集群节点超时时间
cluster-node-timeout 5000
# 配置数据存储目录
dir "/opt/software/redis/cluster"
# 开启AOF持久化
appendonly yes
# 端口
port 6379
# log日志
logfile "/opt/software/redis/redis-stable/cluster/redis6379.log"
# 集群配置文件
cluster-config-file nodes-6379.conf
# AOF文件名
appendfilename "appendonly6379.aof"
# RBD文件名
dbfilename "dump6379.rdb"

6380 端口集群配置：

bash 复制代码 
# 允许所有的IP地址
bind * -::*
# 后台运行
daemonize yes
# 允许远程连接
protected-mode no
# 开启集群模式
cluster-enabled yes
# 集群节点超时时间
cluster-node-timeout 5000
# 配置数据存储目录
dir "/opt/software/redis/cluster"
# 开启AOF持久化
appendonly yes
# 端口
port 6380
# log日志
logfile "/opt/software/redis/redis-stable/cluster/redis6380.log"
# 集群配置文件
cluster-config-file nodes-6380.conf
# AOF文件名
appendfilename "appendonly6380.aof"
# RBD文件名
dbfilename "dump6380.rdb"

✅4. 集群数据读写

bash 复制代码 
# 连接一个主节点进行写数据
redis-cli info replication

📝 注意： 直接连接读写可能会出现错误，因为不同的节点负责不同的槽位，会提示去正确的节点进行写入数据。

可以通过开启路由规则 -c 来自动重定向：

bash 复制代码 
# 开启路由规则 -c
redis-cli -c

# 重新写入数据，恢复正常
set k1 b1

✅5. 模拟故障转移

bash 复制代码 
# 注意机器 ip 的区分
# 将 129 机器的主节点给干掉（129 的 6379 服务）
redis-cli -p 6379 shutdown

# 查看 129 机器从节点工作日志（131 的 6380 日志）
cat redis6380.log

# 在切换到 132 机器上查看当前集群节点信息，131:6380 已经升为主节点
redis-cli cluster nodes
bash 复制代码 
# 重新启动 129.6379 服务
redis-server ./cluster/redis_6379.conf

# 查看 129.6379 的节点信息，主节点变为从节点
redis-cli -p 6379 info replication

# 观察 131.6380 日志，129.6379 重新加入集群

五、附录：完整配置文件与命令汇总

✅1. 文件目录结构

复制代码 
/opt/software/redis/                           -- Redis 应用
/opt/software/redis/redis-stable               -- Redis 应用根目录
/opt/software/redis/cluster                    -- Redis 集群应用文件目录（日志、快照等信息）
/opt/software/redis/redis-stable/cluster        -- Redis 集群配置文件存放路径（手工创建）

✅2. 各模式配置文件

单机 Redis 配置文件（6379）

所在目录：/opt/software/redis/redis-stable

bash 复制代码 
bind * -::*
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
pidfile /var/run/redis_6379.pid
loglevel notice
logfile /opt/software/redis/redis-stable/redis.log
databases 16
always-show-logo no
set-proc-title yes
proc-title-template "{title} {listen-addr} {server-mode}"
locale-collate ""
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
rdb-del-sync-files no
dir /opt/software/redis
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-sync-max-replicas 0
repl-diskless-load disabled
repl-disable-tcp-nodelay no
replica-priority 100
acllog-max-len 128
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
lazyfree-lazy-user-del no
lazyfree-lazy-user-flush no
oom-score-adj no
oom-score-adj-values 0 200 800
disable-thp yes
appendonly no
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
aof-timestamp-enabled no
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-listpack-entries 512
hash-max-listpack-value 64
list-max-listpack-size -2
list-compress-depth 0
set-max-intset-entries 512
set-max-listpack-entries 128
set-max-listpack-value 64
zset-max-listpack-entries 128
zset-max-listpack-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes
jemalloc-bg-thread yes
主从节点配置

所在目录：/opt/software/redis/redis-stable

主节点 129.6379 配置： 与单机主节点配置一样

从节点 131.6379 配置： 在单机配置基础上增加一行：

bash 复制代码 
replicaof 192.168.75.129 6379

其余配置与主节点相同。大家可以将不同服务器的端口设置不同的值，以方便区分。

132.6379 从节点配置同 131.6379。

哨兵模式配置

所在目录：/opt/software/redis/redis-stable

主从配置无需修改，直接配置 sentinel 文件，3 个机器配置相同：

bash 复制代码 
protected-mode no
port 26379
daemonize yes
pidfile /var/run/redis-sentinel.pid
loglevel notice
logfile /opt/software/redis/redis-stable/sentinel.log
dir /opt/software/redis
sentinel monitor mymaster 192.168.75.129 6379 2
sentinel down-after-milliseconds mymaster 30000
acllog-max-len 128
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no
SENTINEL master-reboot-down-after-period mymaster 0
集群配置

所在目录：/opt/software/redis/redis-stable/cluster，3 个机器配置相同。

6379 配置：

bash 复制代码 
bind * -::*
daemonize yes
protected-mode no
cluster-enabled yes
cluster-node-timeout 5000
dir "/opt/software/redis/cluster"
appendonly yes
port 6379
logfile "/opt/software/redis/redis-stable/cluster/redis6379.log"
cluster-config-file nodes-6379.conf
appendfilename "appendonly6379.aof"
dbfilename "dump6379.rdb"

6380 配置：

bash 复制代码 
bind * -::*
daemonize yes
protected-mode no
cluster-enabled yes
cluster-node-timeout 5000
dir "/opt/software/redis/cluster"
appendonly yes
port 6380
logfile "/opt/software/redis/redis-stable/cluster/redis6380.log"
cluster-config-file nodes-6380.conf
appendfilename "appendonly6380.aof"
dbfilename "dump6380.rdb"

✅3. 完整操作命令汇总

Redis 基础常见命令
命令 说明
keys * 查看当前库所有的 key
exists key 判断某个 key 是否存在
type key 查看 key 值是什么类型
del key 删除指定的 key 数据
unlink key 非阻塞删除，仅将 keys 从 keyspace 元数据中删除，真正的删除在后续异步中操作
ttl key 查看还有多少秒过期，-1 表示永不过期，-2 表示已过期
expire key 秒钟 为给定的 key 设置过期时间
move key dbindex[0-15] 将当前数据库的 key 移动到给定的数据库 db 当中
select dbindex 切换数据库 0-15，默认值为 0
dbsize 查看当前数据库 key 的数量
flushdb 清空当前库
flushall 通杀全部库
单机部署命令
bash 复制代码 
# 关闭防火墙
systemctl stop firewalld.service
firewall-cmd --state
yum remove firewalld

# gcc
gcc --version
yum install gcc

# 下载安装
mkdir -p /opt/software/redis
cd /opt/software/redis
wget https://download.redis.io/redis-stable.tar.gz
tar -xzf redis-stable.tar.gz
cd redis-stable
make install
ll /usr/local/bin

# 启动
./src/redis-server          # 源码路径下启动
redis-server                # /usr/local/bin 下启动

# 配置
vim redis.conf

# 以配置文件启动 + 密码认证登录
redis-server redis.conf
redis-cli -a 1qaz@WSX

# 退出/关闭
quit
redis-cli shutdown
主从部署命令
bash 复制代码 
# 主节点查看从节点信息
info Replication
哨兵部署命令
bash 复制代码 
# 故障模拟
ps aux | grep redis
redis-cli shutdown

# 观察哨兵日志
tail -f sentinel.log

# 重新启动服务
redis-server redis.conf
tail -f sentinel.log
redis-cli -p 26379 info sentinel
tail -f sentinel.log

# 停止哨兵
redis-cli -p 26379 shutdown

# 验证主从切换
redis-cli info replication

# 查看配置文件变化
cat redis.conf
cat sentinel.conf
集群部署命令
bash 复制代码 
# 创建集群目录
mkdir -p /opt/software/redis/redis-stable/cluster
mkdir -p /opt/software/redis/cluster
vim ./cluster/redis_6379.conf
vim ./cluster/redis_6380.conf

# 启动集群服务
redis-server ./cluster/redis_6379.conf
redis-server ./cluster/redis_6380.conf

# 检查服务
ps aux | grep redis

# 创建三主三从集群
redis-cli --cluster create --cluster-replicas 1 \
  192.168.75.129:6379 192.168.75.129:6380 \
  192.168.75.131:6379 192.168.75.131:6380 \
  192.168.75.132:6379 192.168.75.132:6380

# 查看集群信息
redis-cli cluster info
redis-cli info replication
redis-cli cluster nodes

# 停止服务
redis-cli -p 6379 shutdown
redis-cli -p 6380 shutdown

# 集群读写（带路由规则）
redis-cli info replication
redis-cli -c
set k1 b1

# 故障转移模拟
redis-cli -p 6379 shutdown          # 干掉主节点
cat redis6380.log                    # 查看日志
redis-cli cluster nodes              # 查看节点变化
redis-server ./cluster/redis_6379.conf  # 重新启动
redis-cli -p 6379 info replication   # 检查变化

📋 全文总结

✅1. 四种部署模式对比

模式 节点数 高可用 数据分片 适用场景
单机 1 否 否 本地开发、测试
主从 1主+N从 否（需手动切换） 否 读写分离、数据备份
哨兵 1主+N从+N哨兵 是（自动故障转移） 否 中小规模高可用
集群 3主3从（推荐） 是 是（16384槽） 大规模分布式

✅2. 关键演进路径

复制代码 
单机 → 主从（数据冗余 + 读写分离）
     → 哨兵（在主从基础上实现自动故障转移）
     → 集群（数据分片 + 高可用，突破单机内存限制）

✅3. 面试核心要点

  • 主从复制 是 Redis 高可用的基础，数据单向流动（Master → Slave）
  • 哨兵模式 解决主从的自动故障转移问题，但不能保证数据零丢失
  • 集群模式 通过 16384 个哈希槽实现数据分片，CRC16(key) % 16384 定位槽位
  • 哨兵节点应为奇数，选举需 ≥ num/2+1 票
  • 客观下线需要超过 quorum 个哨兵同意
热门推荐
012026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf02GitHub 镜像站点03【AI】2026 年具身智能模型和世界模型总结042026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？052026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？06Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析072026 年 AI 大模型 & AI 编程工具实战全总结082026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？09Trae国际版与国内版深度测评：AI原生IDE的双生花10AI科技热点日报 | 2026年07月01日