NoSQL之Redis配置与优化-EW帮帮网

高并发读写（High Performance）：动态页面生成导致数据库并发负载极高，关系型数据库难以承受上万次/秒的写请求（硬盘I/O瓶颈）。
海量数据存储与访问（Huge Storage）：如SNS网站每天产生数亿条用户动态，关系型数据库在超大规模表中查询效率低下。
高可扩展性与高可用性（High Scalability & Availability）：关系型数据库横向扩展困难，升级和数据迁移需停机维护，影响服务连续性。

（三）Redis简介

1. 基本概念

全称：Remote Dictionary Server（远程字典服务器）。
类型：开源、基于内存、支持持久化的键值对（key-value）NoSQL数据库，用C语言编写。
架构：单进程模型，可在一台服务器启动多个进程以提升并发能力，但需平衡CPU负载。

2. 核心优点

高性能：数据读取速度最高达110000次/秒，写入速度最高达81000次/秒。
丰富数据类型：支持String、List、Hash、Set、Sorted Set等。
持久化机制：支持RDB（快照）和AOF（操作日志）持久化，保障数据不丢失。
原子性：所有操作均为原子性，确保数据一致性。
主从复制与高可用：支持master-slave模式，实现数据备份和故障转移。

3. 应用场景

缓存：热点数据存储，降低数据库压力。
实时统计：如计数器、排行榜（利用Sorted Set）。
消息队列：结合List实现简单队列功能。
社交关系：利用Set存储用户关注、粉丝关系。
实时分析：日志记录与实时数据统计。

二、Redis安装与配置

（一）环境准备

系统：Linux（以CentOS为例）。
依赖工具：tar（解压工具）、gcc（编译工具）、make（编译辅助工具）。

# 安装依赖
yum -y install tar gcc make

（二）下载与解压

官网下载：从Redis官网获取源码包（如redis-6.2.6.tar.gz）。
上传与解压：将安装包上传至Linux服务器/usr/local/src目录并解压。

cd /usr/local/src
tar -xvzf redis-6.2.6.tar.gz
cd redis-6.2.6

（三）编译与安装

Redis源码包自带Makefile，可直接编译安装：

make
# 自定义安装路径（默认安装到/usr/local/redis）
make PREFIX=/usr/local/redis install

（四）创建软链接

将Redis命令添加到系统PATH，方便全局调用：

ln -s /usr/local/redis/bin/* /usr/local/bin/

（五）配置服务脚本

Redis源码包提供install_server.sh脚本用于生成配置文件和启动脚本：

cd utils
./install_server.sh

脚本交互配置（默认值可直接回车）：

端口：6379（默认）。
配置文件路径：/etc/redis/6379.conf。
日志文件路径：/var/log/redis_6379.log。
数据目录：/var/lib/redis/6379。
可执行文件路径：/usr/local/redis/bin/redis-server。

（六）启动与管理服务

1. 启动服务

service redis_6379 start

2. 停止服务

service redis_6379 stop

3. 重启服务

service redis_6379 restart

4. 查看状态

service redis_6379 status

5. 检查端口监听

netstat -anop | grep 6379

三、Redis核心配置文件（`redis.conf`）

（一）基础配置

参数	说明
`bind 127.0.0.1`	绑定监听IP（默认仅本地访问，生产环境需改为服务器IP或`0.0.0.0`允许远程访问）
`port 6379`	服务端口（默认6379）
`daemonize yes`	以守护进程模式运行（`yes`为后台运行，`no`为前台运行）
`pidfile /var/run/redis_6379.pid`	PID文件路径（守护进程模式需配置）
`logfile /var/log/redis_6379.log`	日志文件路径
`loglevel notice`	日志级别（可选`debug`、`verbose`、`notice`、`warning`，默认`notice`）

（二）持久化配置

1. RDB持久化（快照）

原理：定时将内存数据生成快照写入磁盘，通过子进程执行，不阻塞主进程。

配置参数：

save 900 1        # 900秒内至少1个key变更则生成快照
save 300 10       # 300秒内至少10个key变更则生成快照
save 60 10000     # 60秒内至少10000个key变更则生成快照
dbfilename dump.rdb # 快照文件名
dir /var/lib/redis/6379 # 快照存储目录

2. AOF持久化（操作日志）

原理：将每个写操作日志追加到文件中，恢复时重放日志重建数据。

配置参数：

appendonly yes     # 开启AOF（默认`no`）
appendfilename "appendonly.aof" # AOF文件名
appendfsync everysec # 同步策略（`always`：每次写操作同步；`everysec`：每秒同步；`no`：由系统决定）
auto-aof-rewrite-percentage 100 # AOF文件体积比上次重写后增长100%时触发重写
auto-aof-rewrite-min-size 64mb  # AOF文件至少64MB时才触发重写

（三）内存管理配置

参数	说明
`maxmemory <bytes>`	最大内存限制（如`maxmemory 1024mb`表示限制1GB内存）
`maxmemory-policy allkeys-lru`	内存不足时的淘汰策略（可选`volatile-lru`、`allkeys-lru`等，默认`no-enviction`）
`maxclients 10000`	最大客户端连接数（默认10000，`0`表示不限制）

（四）安全配置

参数	说明
`requirepass foobared`	设置访问密码（需通过`AUTH <password>`验证）
`rename-command flushall ""`	重命名危险命令（如将`flushall`重命名为空字符串，禁止使用）

四、Redis命令行工具

（一）`redis-cli`：客户端工具

1. 连接本地Redis

redis-cli
# 或指定端口
redis-cli -p 6379

2. 连接远程Redis

redis-cli -h <远程IP> -p <端口> -a <密码>
# 示例：连接IP为192.168.1.100、端口6379、密码mypassword的Redis
redis-cli -h 192.168.1.100 -p 6379 -a mypassword

3. 常用命令

ping：测试连接是否存活（返回PONG表示正常）。
```
127.0.0.1:6379> ping
PONG
```

set/get：存储/获取字符串数据。

127.0.0.1:6379> set name "John"
OK
127.0.0.1:6379> get name
"John"

keys：查找匹配的key（支持通配符*、?）。

127.0.0.1:6379> keys user:*  # 查找以user:开头的所有key
1) "user:1001"
2) "user:1002"

del：删除指定key。

127.0.0.1:6379> del name
(integer) 1  # 返回1表示删除成功

type：查看key对应的值类型。

127.0.0.1:6379> type user:1001
hash  # 假设user:1001是一个Hash类型

（二）`redis-benchmark`：性能测试工具

1. 基本语法

redis-benchmark [选项] [值]

2. 常用选项

选项	说明
`-h <host>`	目标服务器IP（默认127.0.0.1）
`-p <port>`	目标服务器端口（默认6379）
`-c <num>`	并发连接数（如`-c 100`表示100个并发）
`-n <num>`	总请求数（如`-n 100000`表示10万次请求）
`-d <size>`	SET/GET值的大小（单位字节，如`-d 100`表示值为100字节）
`-t <cmd>`	仅测试指定命令（如`-t set,get`表示仅测试set和get命令）

3. 示例

测试本地Redis性能（100并发，10万次请求）：
```
redis-benchmark -c 100 -n 100000
```

测试远程Redis的set和get命令：

redis-benchmark -h 192.168.1.100 -p 6379 -t set,get -c 200 -n 200000

五、Redis数据类型与常用命令

（一）String（字符串）

1. 特点

单值单键，值可以是字符串、数字或二进制数据（如图片二进制）。
支持最大长度为512MB。

2. 常用命令

命令	说明
`SET key value [EX seconds] [PX milliseconds] [NX	XX]`
`GET key`	获取key的值
`INCR key`	对数值类型的key递增1（若key不存在，初始值为0，递增后为1）
`DECR key`	对数值类型的key递减1
`INCRBY key increment`	对数值类型的key递增指定值（如`INCRBY age 5`）
`DECRBY key decrement`	对数值类型的key递减指定值
`STRLEN key`	获取字符串值的长度

3. 示例

# 设置key为"counter"，值为10，过期时间60秒
127.0.0.1:6379> SET counter 10 EX 60
OK

# 递增counter的值
127.0.0.1:6379> INCR counter
(integer) 11

# 获取counter的值
127.0.0.1:6379> GET counter
"11"

（二）List（列表）

1. 特点

有序、可重复的字符串列表，按插入顺序排序。
基于双向链表实现，支持头部（左）和尾部（右）快速操作。

2. 常用命令

命令	说明
`LPUSH key value1 [value2 ...]`	从列表左侧插入一个或多个值
`RPUSH key value1 [value2 ...]`	从列表右侧插入一个或多个值
`LPOP key`	从列表左侧弹出（删除并返回）第一个元素
`RPOP key`	从列表右侧弹出（删除并返回）最后一个元素
`LRANGE key start stop`	获取列表指定区间的元素（`start`和`stop`为索引，0表示第一个元素，`-1`表示最后一个元素）
`LLEN key`	获取列表长度

3. 示例

# 从右侧插入元素"apple"、"banana"、"cherry"
127.0.0.1:6379> RPUSH fruits apple banana cherry
(integer) 3

# 获取列表所有元素
127.0.0.1:6379> LRANGE fruits 0 -1
1) "apple"
2) "banana"
3) "cherry"

# 从左侧弹出一个元素
127.0.0.1:6379> LPOP fruits
"apple"

# 再次获取列表元素（剩余banana、cherry）
127.0.0.1:6379> LRANGE fruits 0 -1
1) "banana"
2) "cherry"

（三）Hash（哈希）

1. 特点

键值对集合，用于存储对象（如用户信息），每个Hash可包含多个字段（field）和值（value）。
单个Hash最多可包含2^32-1个字段。

2. 常用命令

命令	说明
`HSET key field value [field value ...]`	设置Hash字段的值（可批量设置）
`HGET key field`	获取指定字段的值
`HGETALL key`	获取Hash中所有字段和值
`HDEL key field [field ...]`	删除一个或多个字段
`HLEN key`	获取Hash字段数量
`HEXISTS key field`	判断字段是否存在（存在返回1，不存在返回0）

3. 示例

# 设置用户1001的信息：姓名"Alice"，年龄25，邮箱"alice@example.com"
127.0.0.1:6379> HSET user:1001 name "Alice" age 25 email "alice@example.com"
(integer) 3

# 获取姓名和年龄
127.0.0.1:6379> HGET user:1001 name
"Alice"
127.0.0.

（四）Set（集合）

1. 特点

无序、唯一的字符串集合，基于哈希表实现，添加、删除、查找元素的时间复杂度为 O (1)。
支持集合运算（并集、交集、差集）。

2. 常用命令

命令	说明
`SADD key member [member ...]`	向集合中添加一个或多个元素（重复元素自动忽略）
`SMEMBERS key`	获取集合中所有元素
`SREM key member [member ...]`	从集合中删除一个或多个元素
`SISMEMBER key member`	判断元素是否存在于集合中（存在返回 1，不存在返回 0）
`SCARD key`	获取集合元素数量
`SUNION key1 key2 ...`	计算多个集合的并集
`SINTER key1 key2 ...`	计算多个集合的交集
`SDIFF key1 key2 ...`	计算集合 key1 与其他集合的差集（key1 中存在但其他集合不存在的元素）

3. 示例

# 向集合"students"中添加元素"Bob"、"Charlie"、"David"
127.0.0.1:6379> SADD students Bob Charlie David
(integer) 3

# 判断"Bob"是否在集合中
127.0.0.1:6379> SISMEMBER students Bob
(integer) 1

# 向集合"girls"中添加元素"Alice"、"Bob"
127.0.0.1:6379> SADD girls Alice Bob
(integer) 2

# 计算students和girls的交集（共同元素为"Bob"）
127.0.0.1:6379> SINTER students girls
1) "Bob"

（五）Sorted Set（有序集合）

1. 特点

有序、唯一的字符串集合，每个元素关联一个分数（score），按分数从小到大排序。
基于跳表（Skip List）实现，支持快速范围查询。

2. 常用命令

命令	说明
`ZADD key score1 member1 [score2 member2 ...]`	向有序集合中添加元素及分数（可批量添加）
`ZRANGE key start stop [WITHSCORES]`	按分数升序获取指定区间的元素（`WITHSCORES`返回元素及分数）
`ZREVRANGE key start stop [WITHSCORES]`	按分数降序获取指定区间的元素
`ZREM key member [member ...]`	删除一个或多个元素
`ZSCORE key member`	获取元素的分数
`ZCOUNT key min max`	统计分数在 [min, max] 范围内的元素数量
`ZINCRBY key increment member`	对元素的分数递增指定值（如`ZINCRBY ranks 5 "Alice"`）

3. 示例

# 向有序集合"ranks"中添加元素及其分数：Alice(90)、Bob(85)、Charlie(95)
127.0.0.1:6379> ZADD ranks 90 Alice 85 Bob 95 Charlie
(integer) 3

# 按分数升序获取所有元素及分数
127.0.0.1:6379> ZRANGE ranks 0 -1 WITHSCORES
1) "Bob"
2) "85"
3) "Alice"
4) "90"
5) "Charlie"
6) "95"

# 对Alice的分数递增5分
127.0.0.1:6379> ZINCRBY ranks 5 Alice
"95"

# 按分数降序获取前2名
127.0.0.1:6379> ZREVRANGE ranks 0 1 WITHSCORES
1) "Charlie"
2) "95"
3) "Alice"
4) "95"

六、Redis 持久化机制

（一）RDB（快照持久化）

1. 原理

触发时机：
- 手动触发：执行SAVE（阻塞主进程）或BGSAVE（fork 子进程异步执行）命令。
- 自动触发：根据redis.conf中save配置的时间和 key 变更阈值自动生成快照。
执行流程：
1. 主进程 fork 出子进程，子进程负责生成快照。
2. 子进程将内存数据写入临时文件。
3. 写入完成后，用临时文件替换旧的 RDB 文件。

2. 优缺点

优点	缺点
1. 文件体积小，恢复速度快。 2. 适合大规模数据备份。 3. 对主进程影响小（异步执行时）。	1. 可能丢失最后一次快照后的所有数据。 2. 生成快照时占用内存（子进程复制主进程内存）。

3. 配置示例

# redis.conf中的RDB配置
save 900 1        # 15分钟内至少1个key变更，触发快照
save 300 10       # 5分钟内至少10个key变更，触发快照
save 60 10000     # 1分钟内至少10000个key变更，触发快照
dbfilename dump.rdb # 快照文件名
dir /var/lib/redis/6379 # 存储目录
stop-writes-on-bgsave-error yes # 当快照生成失败时，禁止写入操作（避免数据不一致）

（二）AOF（日志持久化）

1. 原理

日志记录：每当执行写命令（如SET、LPUSH、HSET等）时，将命令以文本形式追加到 AOF 文件中。
恢复数据：重启时按顺序执行 AOF 文件中的命令，重建内存数据。
重写机制（BGREWRITEAOF）：
- 目的：避免 AOF 文件过大，通过删除冗余命令（如多次修改同一 key 的命令合并为最后一次）压缩文件体积。
- 触发方式：
  - 手动触发：执行BGREWRITEAOF命令。
  - 自动触发：根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置自动触发。

2. 优缺点

优点	缺点
1. 数据安全性高，可配置每秒同步或实时同步。 2. 日志文件可读性强，可手动修改（需谨慎）。	1. 文件体积通常大于 RDB 文件。 2. 恢复速度比 RDB 慢（需重放所有命令）。 3. 对性能有一定影响（尤其`appendfsync always`模式）。

3. 配置示例

# redis.conf中的AOF配置
appendonly yes          # 开启AOF
appendfsync everysec    # 同步策略（`always`/`everysec`/`no`）
auto-aof-rewrite-percentage 100 # AOF文件增长100%时触发重写
auto-aof-rewrite-min-size 64mb  # AOF文件至少64MB时触发重写
aof-load-truncated yes  # 当AOF文件损坏时，加载已有的部分数据（默认`yes`）

（三）RDB vs AOF：如何选择？

场景	推荐方案	原因
数据安全性要求不高，追求恢复速度。	仅使用 RDB	RDB 文件小，恢复快，适合缓存场景（允许少量数据丢失）。
数据安全性要求高，允许部分性能损失。	仅使用 AOF（`everysec`策略）	每秒同步兼顾性能和数据安全，最多丢失 1 秒数据。
高并发、高可用场景。	RDB + AOF 混合使用	RDB 用于定期全量备份，AOF 用于实时增量备份，确保数据可靠性。

七、Redis 性能优化与监控

（一）内存优化

1. 内存碎片率（`mem_fragmentation_ratio`）

定义：used_memory_rss（操作系统分配的物理内存）与used_memory（Redis 实际使用的内存）的比值。

监控方法：通过redis-cli info memory命令查看mem_fragmentation_ratio字段。

127.0.0.1:6379> info memory
# Memory
mem_fragmentation_ratio: 1.03  # 理想值在1.0-1.5之间

优化策略：
- 碎片率 > 1.5：重启 Redis（释放内存碎片）或调整内存分配器（如从jemalloc切换为tcmalloc）。
- 碎片率 < 1：说明发生内存交换（swap），需增加物理内存或减少 Redis 内存占用（如设置maxmemory并启用淘汰策略）。

2. 内存使用率（`used_memory`）

监控指标：
- used_memory：Redis 分配的内存总量（含数据和内部开销）。
- maxmemory：配置的最大内存限制。
优化策略：
- 使用 32 位实例：若数据量 < 4GB，使用 32 位 Redis 可减少内存占用（指针大小为 32 位，节省空间）。
- 使用 Hash 结构：将对象属性存储为 Hash 字段，减少 key 数量（如用user:1001的 Hash 存储用户信息，而非多个独立 key）。
- 设置 key 过期时间：对临时数据设置EXPIRE key seconds，避免无效数据长期占用内存。

（二）淘汰策略（`maxmemory-policy`）

当内存使用达到maxmemory时，Redis 根据以下策略淘汰 key：

策略	说明
`volatile-lru`	从已设置过期时间的 key 中，淘汰最近最少使用（LRU）的 key。
`allkeys-lru`	从所有 key 中，淘汰最近最少使用（LRU）的 key。
`volatile-ttl`	从已设置过期时间的 key 中，淘汰即将过期（TTL 最短）的 key。
`volatile-random`	从已设置过期时间的 key 中，随机淘汰 key。
`allkeys-random`	从所有 key 中，随机淘汰 key。
`no-enviction`	禁止淘汰（默认策略，内存不足时写操作报错）。

（三）性能监控命令

1. `info`命令

功能：获取 Redis 服务器的统计信息，支持按模块查询（如memory、stats、persistence等）。
常用子命令：
- info memory：查看内存使用情况。
- info stats：查看命令处理统计（如总请求数、淘汰 key 数量evicted_keys）。
- info persistence：查看持久化状态（如 RDB/AOF 最后一次执行时间、是否成功）。

2. `monitor`命令

功能：实时监控 Redis 服务器接收到的所有命令（谨慎用于生产环境，可能影响性能）。
```
127.0.0.1:6379> monitor
OK
1688493721.123456 [0 127.0.0.1:54321] "set" "test" "value"
```

（四）其他优化建议

1. 避免大 key

问题：大 key（如巨型 String 或包含数万元素的 List/Set）会导致网络延迟、内存分布不均，甚至引发阻塞。
优化方法：
- 拆分大集合（如将一个包含 10 万元素的 List 拆分为多个小 List，按时间或类别分片）。
- 使用SCAN命令替代KEYS *遍历 key（KEYS命令会阻塞主进程，SCAN为渐进式遍历）。

2. 减少网络开销

使用管道（Pipeline）：将多个命令打包发送，减少往返次数（如批量执行MSET、MGET）。

# 管道示例（redis-cli中使用）
127.0.0.1:6379> pipeline
> set key1 value1
> set key2 value2
> exec
1) OK
2) OK

合理设置tcp-backlog：在redis.conf中配置tcp-backlog 511（提高 TCP 三次握手阶段的连接队列长度，应对突发高并发）。

3. 主从复制与集群

主从复制：
- 配置从服务器（slaveof <master_ip> <master_port>），实现读写分离（主节点写，从节点读）。
- 主节点配置masterauth <password>，从节点配置masterauth验证主节点密码。
集群（Cluster）：
- 使用 Redis Cluster 实现数据分片（Sharding），将数据分布到多个节点，突破单节点内存限制。
- 每个集群至少需要 3 个主节点和 3 个从节点，提供高可用性和自动故障转移。

八、实战案例：Redis 在缓存场景中的应用

（一）需求场景

某电商网站需要缓存商品详情页数据（如商品信息、库存、价格），减少数据库压力，提升访问速度。
数据特点：读多写少，允许偶尔脏数据（缓存与数据库短暂不一致）。

（二）解决方案

1. 数据模型设计

Key 命名规范：cache:product:{product_id}（如cache:product:1001）。
值类型：使用 Hash 存储商品字段（如name、price、stock、update_time）。

2. 缓存写入流程

# 伪代码：更新商品信息时同时更新缓存
def update_product(product_id, data):
    # 写入数据库
    db.update("products", product_id, data)
    # 写入Redis缓存（设置过期时间300秒）
    redis.hset("cache:product:" + product_id, mapping=data)
    redis.expire("cache:product:" + product_id, 300)

3. 缓存读取流程

# 伪代码：读取商品信息时先查缓存，再查数据库
def get_product(product_id):
    # 从Redis获取缓存
    cache_key = "cache:product:" + product_id
    product = redis.hgetall(cache_key)
    if product:
        return product
    else:
        # 从数据库查询
        product = db.query("products", product_id)
        if product:
            # 写入缓存
            redis.hset(cache_key, mapping=product)
            redis.expire(cache_key, 300)
        return product

4. 缓存淘汰与更新策略

过期时间：设置EXPIRE cache:product:{product_id} 300，避免冷数据长期占用内存。
更新策略：
- 商品修改时主动更新缓存（保证数据一致性）。
- 缓存过期后，通过数据库加载最新数据并重建缓存（懒加载）。

九、常见问题与解决方案

（一）数据丢失问题

1. 场景 1：未开启持久化，Redis 重启后数据丢失

解决方案：
- 启用 RDB 或 AOF 持久化（推荐同时启用 RDB 定期全量备份和 AOF 实时增量备份）。
- 配置save规则和appendonly yes，并定期备份持久化文件到外部存储（如 OSS、NFS）。

2. 场景 2：AOF 文件损坏，无法恢复数据

解决方案：
- 使用redis-check-aof --fix <aof文件路径>修复损坏的 AOF 文件。

（二）性能瓶颈问题

1. 场景 1：Redis 响应延迟突然升高

可能原因：
- 主进程正在执行阻塞操作（如SAVE、FLUSHALL）。
- 内存碎片率过高，导致频繁内存交换。
- 网络延迟或客户端连接数达到上限。
解决方案：
- 避免阻塞命令：用BGSAVE替代SAVE，避免在生产环境执行FLUSHALL等危险命令。
- 监控内存碎片：通过info memory查看mem_fragmentation_ratio，若 > 1.5 则重启 Redis 或调整内存分配器。
- 调整连接数限制：在redis.conf中增大maxclients（如maxclients 20000），并检查网络带宽是否充足。

2. 场景 2：高并发下写入性能下降

可能原因：
- 单线程模型下，写命令处理速度无法匹配并发请求。
- 持久化策略设置过严（如appendfsync always）。
解决方案：
- 开启多线程（Redis 6.0+）：在redis.conf中配置io-threads-do-reads yes和io-threads 4（根据 CPU 核心数调整），提升读性能；写操作仍由主线程处理，可通过优化数据模型减少写压力。
- 调整 AOF 同步策略：将appendfsync从always改为everysec，降低磁盘 I/O 对写性能的影响。

（三）主从复制异常

1. 场景 1：从节点无法同步主节点数据

可能原因：
- 主节点配置错误（如未开启持久化，导致从节点首次同步失败）。
- 网络连接问题（防火墙阻止主从节点通信）。
- 主节点密码验证失败（从节点未配置masterauth）。
解决方案：
- 检查主节点配置：确保主节点开启 RDB 或 AOF 持久化，且bind地址允许从节点访问（如bind 0.0.0.0）。
- 配置防火墙规则：开放主节点端口（默认 6379）和从节点通信端口。
- 设置主节点密码：在主节点redis.conf中添加requirepass mypassword，从节点配置masterauth mypassword。

2. 场景 2：主从延迟过高

可能原因：
- 主节点写操作压力过大，导致复制积压缓冲区（replication backlog）溢出。
- 从节点硬件性能不足（如磁盘 I/O 慢，导致持久化延迟）。
解决方案：
- 增大复制积压缓冲区：在redis.conf中配置repl-backlog-size 256mb（根据主节点写流量调整），避免小缓冲区导致的全量同步。
- 优化从节点配置：将从节点read-only yes（默认开启），并关闭从节点持久化（若仅用于读服务），提升复制效率。

（四）大 Key 问题

1. 定位大 Key

命令行工具：
- 使用redis-cli --bigkeys扫描大 Key（需在 Redis 服务器上执行）：
```
redis-cli --bigkeys -h 192.168.1.100 -p 6379 -a mypassword
```
- 输出结果会显示各数据类型中占用内存最大的 Key（如 Biggest string found 'user:1001' has 1024 bytes）。

2. 优化大 Key

拆分 String 类型大 Key：将大字符串拆分为多个子 Key（如按字段拆分用户信息为多个 Hash 字段）。
分片集合类型大 Key：将大 List/Set/Sorted Set 按一定规则分片（如按时间戳取模存储到不同 Key）：
```
# 示例：将订单列表按天分片
RPUSH orders:2023-10-01 "order_1001"
RPUSH orders:2023-10-02 "order_1002"
```
使用流水线（Pipeline）操作：批量处理大集合的读写，减少网络往返次数。

（五）缓存穿透与击穿

1. 缓存穿透（查询不存在的 Key 导致数据库压力）

解决方案：
- 布隆过滤器（Bloom Filter）：在查询前用布隆过滤器判断 Key 是否存在，避免无效查询穿透到数据库。
- 空值缓存：对不存在的 Key 设置短时间缓存（如SET nonexist_key "" EX 60），防止重复查询。

2. 缓存击穿（热点 Key 过期瞬间大量请求直达数据库）

解决方案：
- 延长热点 Key 过期时间：结合业务场景设置较长的过期时间（如EXPIRE hot_key 86400）。
- 加互斥锁：在缓存失效时，通过SET hot_key_lock "" NX EX 10获取锁，确保只有一个线程重建缓存，其他线程等待锁释放后读取缓存。

十、Redis 最佳实践总结

（一）配置优化清单

优化项	推荐配置
绑定 IP	`bind 0.0.0.0`（生产环境绑定服务器公网 IP 或内网 IP）
守护进程模式	`daemonize yes`
最大内存限制	`maxmemory 8gb`（根据服务器内存大小设置，建议预留 20% 内存用于操作系统和缓存）
淘汰策略	`maxmemory-policy allkeys-lru`
RDB 自动快照	`save 3600 1`（每天至少 1 次全量备份）
AOF 同步策略	`appendfsync everysec`
关闭不必要的命令	`rename-command DEBUG ""`（禁用危险命令如`DEBUG`、`FLUSHALL`）

（二）监控指标清单

指标	工具 / 命令	阈值建议
内存使用率（`used_memory`）	`info memory`	< 80% of `maxmemory`
内存碎片率（`mem_fragmentation_ratio`）	`info memory`	1.0 < 值 < 1.5
客户端连接数（`connected_clients`）	`info clients`	< `maxclients` × 0.9
每秒请求数（`instantaneous_ops_per_sec`）	`info stats`	< 50000 次 / 秒（根据服务器配置调整）
持久化延迟（`aof_last_rewrite_time_sec`/`rdb_last_bgsave_status`）	`info persistence`	状态为`ok`，耗时 < 60 秒

（三）运维规范

备份策略：
- 每天凌晨执行 RDB 全量备份，并将备份文件压缩后上传至云端存储（如 AWS S3、阿里云 OSS）。
- 实时同步 AOF 文件到从节点或备用服务器，确保数据可恢复。
灰度发布：
- 配置变更或版本升级时，先在测试环境验证，再逐步发布到生产环境（如先升级从节点，再切换主节点）。
应急响应：
- 编写应急预案，包括数据恢复流程、主从切换步骤、内存不足时的紧急淘汰策略。
- 使用监控工具（如 Prometheus+Grafana）设置告警规则，实时通知性能异常和故障。