1. 任意方法安装Redis
apt install redis -y
2. redis的配置文件在哪里？默认端口是多少
默认端口： Redis 的默认端口是 6379。
配置文件：通过 Linux 包管理器（如 apt 或 yum）安装，通常位于 /etc/redis/redis.conf。
3. redis主要功能是什么？与MySQL有什么不同
Redis（Remote Dictionary Server） 是一个开源的 内存型键值数据库（In-memory Key-Value Store），它支持多种数据结构，并提供了丰富的功能，主要用于 缓存、消息队列、会话管理、分布式锁 等场景。
Redis 的主要功能
Redis 与 MySQL 的主要区别
4. 尝试set一些数据，并使用get验证
1. 启动 Redis 客户端
打开终端或命令行工具，输入以下命令以连接到本地 Redis 服务器：
redis-cli如果 Redis 服务器运行在远程主机上，可以指定主机和端口：
redis-cli -h <host> -p <port>2. 设置数据 (SET)
在 Redis 命令行中，使用 SET 命令存储键值对。例如：
127.0.0.1:6379> SET name Alice
OK3. 获取数据 (GET)
使用 GET 命令获取之前存储的键值对。例如：
127.0.0.1:6379> GET name
"Alice"4. 退出 Redis 命令行
完成操作后，可以通过以下命令退出 Redis 命令行：
127.0.0.1:6379> exit
5. redis的数据保存在哪里
Redis 是一个内存数据库，数据主要存储在内存中。不过 Redis 提供了持久化功能，可以将数据保存到磁盘上，确保在服务重启或意外关闭后数据不会丢失。
6. redis持久化是什么意思，有哪几种方式，各有什么优缺点，如何配置
1. Redis 数据存储的两种方式
Redis 支持两种主要的持久化机制：
(1) RDB（Redis Database Backup）
RDB 是 Redis 的默认持久化机制。
它会在指定的时间间隔内将内存中的数据快照写入磁盘，生成一个
dump.rdb文件。优点：文件紧凑、恢复速度快。
缺点：可能会丢失最后一次快照之后的数据。
配置项（在 redis.conf 文件中）：
save 900 1 # 表示在 900 秒内，至少有 1 个键被修改时触发 RDB 快照
save 300 10 # 在 300 秒内，至少有 10 个键被修改时触发
save 60 10000 # 在 60 秒内，至少有 10000 个键被修改时触发RDB 文件路径和名称：
dir ./
dbfilename dump.rdb(2) AOF（Append Only File）
AOF 持久化机制会记录所有写操作命令，并以追加的方式写入日志文件。
优点：数据安全性更高，支持多种同步策略。
缺点：文件体积较大，恢复速度较慢。
启用 AOF（在 redis.conf 中设置）：
appendonly yes
appendfilename "appendonly.aof"AOF 同步策略（appendfsync）：
always：每次写操作都同步到磁盘（最安全，性能最低）everysec：每秒同步一次（推荐，平衡安全性和性能）no：由操作系统决定何时同步（最快，但可能丢失较多数据）
2. 如何查看 Redis 数据存储的位置
你可以通过以下命令查看 Redis 的持久化配置和文件路径：
查看当前 Redis 配置
127.0.0.1:6379> CONFIG GET dir
127.0.0.1:6379> CONFIG GET dbfilename
127.0.0.1:6379> CONFIG GET appendfilename
3. Redis 数据文件的实际位置
假设你的 Redis 配置如下：
dir /var/lib/redis
dbfilename dump.rdb
appendfilename appendonly.aof那么 Redis 的数据文件通常会保存在 /var/lib/redis 目录下：
dump.rdb：RDB 快照文件appendonly.aof：AOF 日志文件
4. 总结
默认情况下，Redis 数据保存在内存中，但可以通过 RDB 或 AOF 持久化到磁盘。
RDB 文件：用于全量备份，默认名为
dump.rdb。AOF 文件：用于记录所有写操作，默认名为
appendonly.aof。数据文件路径：可以在
redis.conf配置文件中通过dir参数指定。
7. 什么是redis的缓存雪崩、穿透和击穿
1. 缓存雪崩（Cache Avalanche）
定义：
当某一时刻，大量缓存同时失效或 Redis 服务宕机重启，所有请求都会落到数据库上，可能会导致数据库瞬间压力过大甚至崩溃。
2. 缓存穿透（Cache Penetration）
定义：
查询一个既不在缓存也不在数据库中的数据（如非法 ID），每次请求都会穿透到数据库，恶意攻击者可能利用此进行攻击。
3. 缓存击穿（Cache Breakdown）
定义：
某个热点 key 突然失效，大量并发请求直接打到数据库，可能导致数据库负载过高。
8. 搭建redis的主从复制
一、环境准备
假设你有三台服务器（或本机多实例）用于搭建 Redis 主从架构：
二、配置主节点（Master）
1. 修改 redis.conf
编辑主节点的 Redis 配置文件（通常在 /etc/redis/redis.conf 或你安装的目录下）：
bind 0.0.0.0 # 允许所有 IP 连接
port 6379
daemonize yes # 启动为守护进程
requirepass yourpassword # 可选：设置密码（建议）2. 启动 Redis 主节点
redis-server /path/to/redis.conf三、配置从节点（Slave）
1. 修改从节点的 redis.conf
bind 0.0.0.0
port 6379
daemonize yes
slaveof 192.168.1.100 6379 # 指定主节点的 IP 和端口
masterauth yourpassword # 如果主节点设置了密码，必须配置
requirepass yourpassword # 可选：设置从节点密码说明：
slaveof是配置从节点的关键指令，表示该节点从哪个主节点同步数据。
2. 启动 Redis 从节点
redis-server /path/to/redis.conf四、验证主从复制是否生效
1. 在主节点设置数据
redis-cli -h 192.168.1.100
192.168.1.100:6379> SET name "Redis Master"2. 在从节点读取数据
redis-cli -h 192.168.1.101
192.168.1.101:6379> GET name
"Redis Master"🧪 五、查看主从状态
在任意节点执行以下命令，查看主从关系：
redis-cli info replication
9. 搭建Redis的哨兵，并尝试进行主节点的切换
一、环境准备
我们以三台服务器为例，构建一个简单的 Redis 主从 + Sentinel 架构：
说明：每个 Redis 实例都搭配一个 Sentinel 进程，也可以单独部署 Sentinel。
二、配置 Redis 主从复制（已完成可跳过）
确保 Redis 主从已经配置好，参考上一条关于“主从复制”的配置方法。
三、配置 Redis Sentinel
1. 创建 sentinel.conf 文件
在每台机器上创建 Sentinel 的配置文件，通常放在 /etc/redis/sentinel.conf 或你自定义的位置。
示例配置内容：
port 26379
dir /tmp
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel auth-pass mymaster yourpassword
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1参数说明：
sentinel monitor mymaster <ip> <port> <quorum>：mymaster是主节点的逻辑名称。<quorum>表示至少有几个 Sentinel 认为该主节点下线才会触发故障转移（一般设置为 Sentinel 总数的一半加一）。
sentinel auth-pass：如果主节点设置了密码，必须配置。down-after-milliseconds：超过多少毫秒未响应视为节点宕机。failover-timeout：故障转移超时时间。parallel-syncs：故障转移后同时同步从节点的数量。
四、启动 Sentinel
使用以下命令启动 Sentinel（假设配置文件路径为 /etc/redis/sentinel.conf）：
redis-sentinel /etc/redis/sentinel.conf五、验证 Sentinel 是否正常工作
1. 查看 Sentinel 状态
连接到任意 Sentinel 节点：
redis-cli -p 26379
127.0.0.1:26379> sentinel masters
10. 搭建Redis的集群模式并与主从模式和哨兵模式进行对比，各有什么优点
Redis 提供了三种常见的部署模式：单机模式、主从复制模式、哨兵模式（Sentinel） 和 集群模式（Cluster）。每种模式适用于不同的业务场景和高可用性需求。下面我们来搭建 Redis 集群模式，并对主从模式、哨兵模式和集群模式进行对比分析。
11. Redis集群的槽位是干啥的
Redis 集群中的 槽位（Hash Slot） 是实现数据分片（Sharding）的核心机制。Redis Cluster 将整个数据集划分为 16384 个哈希槽（slots），每个键通过 CRC16 算法计算出一个哈希值，再对 16384 取模，最终映射到一个具体的槽位上。
1. 数据分片
Redis Cluster 使用槽位将数据分布到多个节点上。
每个主节点负责一部分槽位（例如：Node A 负责 0
5500，Node B 负责 550111000，Node C 负责 11001~16383）。这样可以实现横向扩展，提升整体性能和容量。
2. 实现去中心化架构
所有节点都知道所有槽位的归属信息，无需依赖中心节点（如 ZooKeeper 或 Redis Proxy）。
节点之间通过 Gossip 协议交换集群状态信息。
3. 支持动态扩容/缩容
当新增或移除节点时，Redis Cluster 可以在不停机的情况下重新分配槽位。
槽位迁移过程中，客户端请求会被自动重定向。
12. Redis的集群模式最大分片数是多少，为什么是这个数字
Redis 集群模式的最大分片数是 16384 个哈希槽（Hash Slots）。
一、最大分片数是多少？
Redis Cluster 将整个键空间划分为 16384 个哈希槽（编号从 0 到 16383），这是 Redis 官方硬编码设定的值，不可更改。
每个 key 通过以下方式决定它属于哪个槽：
slot = CRC16(key) % 16384二、为什么选择 16384 这个数字？
这个数值的选择并非随意，而是基于以下几个关键因素的权衡：
1. 节点通信开销控制
Redis Cluster 使用 Gossip 协议在节点之间交换信息。
每个节点需要广播自己负责的槽位范围。
如果槽位数量太多（比如 65536），会显著增加通信开销和内存占用。
16384 是一个足够小的数字，可以将每个节点的槽位信息压缩到一个 MTU（Maximum Transmission Unit）范围内，从而减少网络传输负担。
2. 支持合理的集群规模
假设每个主节点平均管理 1000 个槽位，则 16384 可以支持大约 16 个主节点。
对于大多数实际应用场景来说，这已经足够满足需求。
如果你真的需要更多节点，可以通过客户端分片（Client-side Sharding）实现更大规模部署。
3. 平衡数据分布与性能
如果槽位太少（如 1024），会导致数据分布不均，某些节点负载过高。
如果槽位太多（如 65536），虽然能提高均匀性，但增加了维护成本和网络开销。
16384 是一个折中方案，既能保证较好的数据分布，又不会造成太大的额外开销。
4. 内存效率优化
每个节点使用一个位图（bitmap）来记录哪些槽属于自己。
16384 个槽只需要 2KB 的内存空间（16384 bits = 2048 bytes）。
如果是 65536 个槽，则需要 8KB，虽然不多，但在大规模集群中会累积。
13. 如何进行Redis集群的备份和还原，有哪些注意事项
Redis 集群的备份与还原是保障数据安全的重要操作。虽然 Redis Cluster 是分布式系统，但其备份和还原策略与单机模式类似，主要依赖于 RDB（Redis Database Backup）持久化机制。
一、Redis 集群的备份方式
1. 使用 RDB 快照进行备份（推荐）
每个 Redis 节点都可以配置 RDB 持久化，定期将内存数据快照写入磁盘文件 dump.rdb。
步骤：
确保所有节点启用了 RDB 持久化
在每个节点的 redis.conf 中配置：
save 900 1 # 每 15 分钟至少修改 1 个 key 时触发保存
save 300 10 # 每 5 分钟至少修改 10 个 key 时触发
save 60 10000 # 每 1 分钟至少修改 10000 个 key 时触发
dir /var/lib/redis
dbfilename dump.rdb手动执行 SAVE 或 BGSAVE 命令（可选）
连接到任意主节点执行：
redis-cli -c -p 6380
127.0.0.1:6380> BGSAVE注意：BGSAVE 是异步的，不会阻塞 Redis 主进程。
复制所有节点的 dump.rdb 文件到安全位置
你需要在每个节点上执行：
cp /var/lib/redis/dump.rdb /backup/redis_node1.rdb二、Redis 集群的还原方式
1. 单节点还原（适用于局部恢复）
步骤：
停止目标节点服务
redis-cli -p 6380 shutdown替换 dump.rdb 文件
cp /backup/redis_node1.rdb /var/lib/redis/dump.rdb启动 Redis 节点
redis-server /path/to/redis.conf加入集群
redis-cli --cluster add-node 192.168.1.100:6380 192.168.1.100:63802. 全量恢复整个集群（需全部节点参与）
步骤：
停止所有 Redis 节点
redis-cli -p 6380 shutdown恢复所有节点的 dump.rdb 文件
cp /backup/redis_node1.rdb /var/lib/redis/dump.rdb
cp /backup/redis_node2.rdb /var/lib/redis/dump.rdb
...重启所有节点
redis-server /path/to/redis.conf重新构建集群（如果元数据丢失）
redis-cli --cluster create \
192.168.1.100:6380 \
192.168.1.101:6380 \
192.168.1.102:6380 \
192.168.1.100:6381 \
192.168.1.101:6381 \
192.168.1.102:6381 \
--cluster-replicas 1
14. redis如何禁用命令，要禁用哪些命令。
在 Redis 中，为了提高系统的安全性和稳定性，可以通过配置文件禁用一些高风险或不常用的命令。禁用命令是通过 redis.conf 文件中的 rename-command 指令实现的。
一、Redis 禁用命令的方法
1. 修改 redis.conf 文件
使用 rename-command 指令将命令重命名为一个空字符串（即禁用）：
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command KEYS ""
rename-command PUBLISH ""
rename-command SUBSCRIBE ""
rename-command EVAL ""
rename-command DEBUG ""
rename-command SHUTDOWN ""
rename-command MONITOR ""2. 启用配置并重启 Redis
保存配置后，重启 Redis 服务使配置生效：
redis-cli shutdown
redis-server /path/to/redis.conf
以下是一些建议禁用或重命名的命令，按风险等级排序：
15. keys *的作用是什么，线上环境可以使用吗？应该使用什么命令代替
EYS * 的作用
KEYS * 是 Redis 中一个非常强大的命令，用于列出当前数据库中所有键（keys）。
语法：
KEYS patternpattern是匹配规则，支持通配符：*：匹配任意数量的字符（如KEYS user:*）。?：匹配单个字符。[]：匹配括号中的任意一个字符。
线上环境可以使用 KEYS * 吗？
不推荐在生产环境使用 KEYS *，原因如下：
替代方案：使用 SCAN 命令
Redis 提供了 SCAN 命令作为 KEYS 的安全替代方案。
SCAN 的特点：
非阻塞：不会一次性扫描所有 key，而是分批次返回。
可中断：客户端可以随时停止扫描。
支持匹配模式：如
SCAN 0 MATCH user:* COUNT 100
127.0.0.1:6379> SCAN 0 MATCH * COUNT 10
1) "17" # 下一个游标值
2) 1) "user:1000"
2) "session:abc123"
3) "counter"
...0是游标起始值。COUNT表示每次返回的 key 数量（只是一个建议值）。当游标返回
0时，表示扫描完成。
