NoSQL 之 Redis 配置与优化

目录

一、 前置知识点

1.  关系数据库与非关系型数据库

（1）关系型数据库

（2）非关系型数据库

（3）非关系型数据库产生背景

（4）两者对比

2. Redis 基础

（1）Redis 简介

（2）Redis 安装部署

（3）配置参数

3. Redis 命令工具

（1）redis-cli 命令行工具

（2）redis-benchmark 测试工具

4. Redis 数据库常用命令

（1）命令

（2）多数据库常用命令

二、Redis 持久化

1.  持久化概述

2. 持久化分类

3. RDB 和 AOF 的区别

4. RDB 和 AOF 的优缺点

（1）RDB 优缺点

（2）AOF 优缺点

5. Redis 持久化配置

（1）RDB 持久化配置

（2）AOF 持久化配置

6. AOF 重写

为什么需要重写？

三、性能管理

1. 内存碎片率（Mem Fragmentation Ratio）

定义

监控方法

优化策略

2. 内存使用率（Memory Utilization）

定义

监控方法

优化策略

3. 回收 Key（Key Eviction & Deletion）

自动回收（淘汰策略）

手动回收（主动删除）

过期 Key 管理

---

一、 前置知识点

1.  关系数据库与非关系型数据库

（1）关系型数据库

• 定义：采用关系模型来组织数据的数据库，关系模型即二维表格模型，由二维表及其之间的联系组成数据组织。

• 特点：

  • 结构化数据：数据以行和列的方式存储在表格中，具有严格的行列结构。

  • ACID 特性：支持事务，确保数据的原子性、一致性、隔离性和持久性。

  • 强关系支持：通过主键、外键和索引实现表间关系。

  • 标准化查询：支持标准 SQL 语句，可方便地在一个表以及多个表之间做复杂的数据查询。

• 典型例子：MySQL、PostgreSQL、Oracle、SQL Server 等。

• 适用场景：适用于需要处理复杂关系、保证数据一致性和完整性的场景，如银行系统、电子商务系统的订单处理等。

（2）非关系型数据库

• 定义：非关系型的、分布式的，且一般不保证遵循 ACID 原则的数据存储系统。

• 特点：

  • 灵活数据模型：支持键值对、文档、列族或图等模型，适合非结构化或半结构化数据。

  • 高性能和高扩展性：支持高并发读写，易于水平扩展。

  • 无固定模式：数据结构可以动态变化，无需严格定义模式。

  • 弱一致性：优先保证数据的可用性和分区容错性。

• 分类及典型例子：

  • 键值对数据库：如 Redis、Amazon DynamoDB 等，以简单的键值对方式存储数据，读写速度快，常用于缓存、实时数据处理等场景。

  • 文档型数据库：如 MongoDB、CouchDB 等，以文档形式存储数据，文档可以是 JSON、XML 等格式，适合存储半结构化数据，如用户生成的内容、日志等。

  • 列族数据库：如 Cassandra 等，以列为单位存储数据，适合处理大规模的分布式数据，常用于大数据存储和分析场景。

  • 图数据库：如 Neo4j 等，用于存储图形关系数据，能高效处理复杂的关系查询，适用于社交网络、知识图谱等领域。

• 适用场景：适用于高并发、分布式存储和灵活的非结构化数据场景，如大规模互联网应用、移动应用、物联网等领域。

（3）非关系型数据库产生背景

• High performance ——对数据库高并发读写需求

• Huge Storage —— 对海量数据高效存储与访问需求

• High Scalability && High Availability —— 对数据库高可扩展性与高可

（4）两者对比

• 成本：非关系型数据库简单易部署，基本都是开源软件，相比关系型数据库价格便宜。

• 存储数据的格式：非关系型数据库的存储格式多样，如 key - value 形式、文档形式、图片形式等，可存储基础类型以及对象、集合等各种格式；关系型数据库只支持基础类型。

• 扩展性：关系型数据库因多表查询机制的限制导致扩展艰难；非关系型数据库基于键值对，数据之间没有耦合性，容易水平扩展。

• 数据一致性：关系型数据库强调数据的强一致性；非关系型数据库一般强调数据最终一致性。

• 事务处理：关系型数据库支持事务处理；非关系型数据库一般不提供对事务的处理。

2. Redis 基础

（1）Redis 简介

• 概述：  

  •  基于内存运行并支持持久化

  •  采用key-value(键值对)的存储形式

• 优点：

  • 具有极高的数据读写速度

  • 支持丰富的数据类型

  • 支持数据的持久化

  • 原子性

  • 支持数据备份

（2）Redis 安装部署

--关闭防火墙
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0
--安装依赖环境
dnf -y install gcc zlib-devel
--解压redis包
tar zxvf redis
cd redis
--make安装(redis 源码包直接提供了Makefile)
make
make PREFIX=/usr/local/redis install
--软链接环境变量
ln -s /usr/local/redis/bin/* /usr/local/bin/
--初始化
cd /root/redis/utils
./install_server.sh   (一直回车保持默认位置就OK)`Selecting default: 6379   默认端口
`Please select the redis config file name   文件位置`[/etc/redis/6379.conf] 
`Please select the redis log file name     日志文件位置[/var/log/redis_6379.log] 
"Please select the data directory for this instance [/var/lib/redis/6379] "    
Please select the redis executable path [/usr/local/bin/redis-server] Please select the data directory for this instance [/var/lib/redis/6379]--查看启动是否（默认监听回环，无法远程）
netstat -anpt | grep redis
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      5953/redis-server 1

（3）配置参数

--改配置
vi /etc/redis/6379.conf 
bind 127.0.0.1 192.168.10.101   //监听的主机地址
port 6379  //端口
daemonize yes //启用守护进程
pidfile /var/run/redis_6379.pid  //指定PID文件
loglevel notice  //日志级别
lofile /var/log/redis_6379.log  //指定日志文件
--重启
/etc/init.d/redis_6379  restart--验证成功是否（多了一行）
netstat -anpt | grep redis
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      5968/redis-server 1 
tcp        0      0 192.168.10.101:6379     0.0.0.0:*               LISTEN      5968/redis-server 1 

3. Redis 命令工具

（1）redis-cli 命令行工具

--登录redis(直接登无密码，存的是非结构化数据)
redis-cli		//本地连
redis-cli -h 192.168.10.101 -p 6379    //远程连

（2）redis-benchmark 测试工具

4. Redis 数据库常用命令

（1）命令

采用 key-value(键值对)的数据存储形式

set : 存放数据，基础格式为 set key value
get : 获取数据，基础格式为 get key

keys 命令

keys 命令符合规则的键值列表，通常情况可以结合*、？等选项来使用
keys *     //查看当前数据库中所有键
keys v*   //查看当前数据库中以v开头的数据
keys v?  //查看当前数据库中以v开头后面包含任意一位的数据
keys v??    //查看当前数据中以v开头v开头后面包含任意两位的数据

exists 命令 

exists 命令可以判断键值是否存在
格式： exists 键名
例如：
exists teacher
(integer) 1  //表示 teacher 键是存在
(integer) 0  //表示 tea 键不存在

del 命令 

del 命令可以删除当前数据库的指定 key
keys *
del 指定键

type 命令 

type 命令可以获取key对应的value值类型

rename 命令 

rename 命令是对已有key进行重命名
命令格式：rename 源key 目标key
例如：rename v22 v2容易出错若出现同名则会覆盖
可以使用exists先检查是否存在，或者renamenx

renamenx 命令 

renamenx : 可检测目标（新名）是否存在，避免冲突覆盖，存在则不进行

dbsize 命令 

dbsize 命令的作用是查看当前数据库中key 的数目

（2）多数据库常用命令

二、Redis 持久化

1.  持久化概述

    运行在内存，容易丢，为防止，则要把数据写入磁盘空间中，即为持久化

2. 持久化分类

• RDB方式：默认方式，创建快照的方式获取当时的所有信息数据

• AOF（Append Only File）方式：仅仅在文件末尾追加信息，以日志方式记录数据变化

3. RDB 和 AOF 的区别

维度	RDB (Redis Database)	AOF (Append Only File)
持久化方式	定时生成内存快照（二进制文件）	记录每次写操作命令（文本文件）
数据完整性	可能丢失最后一次快照后的数据	最多丢失 1 秒数据（取决于 fsync 策略）
文件大小	小（压缩二进制）	大（命令文本）
恢复速度	快（直接加载二进制）	慢（需重放所有命令）
资源消耗	高（fork 子进程时 CPU/内存峰值）	低（追加写入）

核心差异：

• RDB 是数据快照，AOF 是操作日志

• RDB 适合灾难恢复，AOF 适合数据安全

4. RDB 和 AOF 的优缺点

（1）RDB 优缺点

优点	缺点
① 恢复速度快（大数据集秒级加载）	① 可能丢失分钟级数据
② 文件紧凑（适合备份/迁移）	② fork 子进程时内存占用翻倍
③ 最大化 Redis 性能（持久化时不影响主进程）	③ 数据完整性低

适用场景：

• 允许丢失部分数据的缓存服务

• 需要快速恢复的大数据集

（2）AOF 优缺点

优点	缺点
① 数据安全（最多丢失 1 秒数据）	① 文件体积大（需定期重写）
② 实时持久化（每次写操作记录）	② 恢复速度慢（需重放日志）
③ 可读性好（文本格式查看历史操作）	③ 写入性能略低于 RDB（fsync 开销）

适用场景：

• 金融交易等对数据完整性要求高的场景

• 需要审计操作历史的系统

5. Redis 持久化配置

（1）RDB 持久化配置

# 触发规则：900秒内至少1次修改  
save 900 1  
# 触发规则：300秒内至少10次修改  
save 300 10  
# 触发规则：60秒内至少10000次修改  
save 60 10000  # RDB文件名  
dbfilename dump.rdb  # 工作目录（持久化文件存储位置）  
dir /var/lib/redis  # 压缩存储  
rdbcompression yes  

（2）AOF 持久化配置

# 启用 AOF  
appendonly yes  # AOF 文件名  
appendfilename "appendonly.aof"  # 同步策略  
appendfsync everysec  # 推荐值：每秒同步（平衡性能与安全）  
# appendfsync always  # 每次写操作同步（最安全）  
# appendfsync no      # 由操作系统决定（性能最好）  # AOF 重写触发条件  
auto-aof-rewrite-percentage 100  # 文件增长超过100%时触发  
auto-aof-rewrite-min-size 64mb   # 最小重写文件大小  

6. AOF 重写

为什么需要重写？

• 问题：AOF 文件持续增长（如执行 100 次 INCR counter 会记录 100 条命令）

• 解决：重写生成精简的新 AOF 文件（如合并为 SET counter 100）

关键步骤：

1. 主进程 fork 子进程

2. 子进程遍历内存数据生成新 AOF 文件

3. 主进程将重写期间的增量命令写入缓冲区

4. 子进程完成时，主进程追加缓冲区命令到新文件

5. 原子替换旧 AOF 文件

 重写配置优化

# 重写期间是否禁用 fsync（提升性能但可能丢失数据）  
no-appendfsync-on-rewrite yes  # 重写触发阈值（默认文件增长100%且大于64MB）  
auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb  

三、性能管理

redis-cli  //登录数据库
info memory    //查看redis 使用内存值

回收策略（文件中带lru的，相关配置）expire name 5   //设置过期时间,自动回收

1. 内存碎片率（Mem Fragmentation Ratio）

定义

• 公式：mem_fragmentation_ratio = used_memory_rss / used_memory
  • used_memory_rss：操作系统分配给 Redis 的物理内存（通过 malloc 分配）。
  • used_memory：Redis 逻辑使用的内存（存储数据实际占用）。
• 理想范围：1.0 ~ 1.5
  • <1：内存不足，可能触发 swap（严重影响性能）。
  • >1.5：碎片率过高，浪费内存。

监控方法

• 命令：INFO MEMORY 查看 mem_fragmentation_ratio。
• 示例输出：

  plaintext

  # Memory
  used_memory:1073741824        # 逻辑内存（1GB）
  used_memory_rss:1572864000    # 物理内存（1.5GB）
  mem_fragmentation_ratio:1.46  # 碎片率
  

优化策略

• 自动碎片整理（4.0 + 版本）
  • 开启配置：

    conf

    activedefrag yes        # 开启主动碎片整理
    active-defrag-threshold-lower 10  # 当碎片率>1.1时触发
    active-defrag-threshold-upper 100 # 碎片率>2时加强整理
    

• 手动整理
  • 执行 BGREWRITEAOF（通过 AOF 重写触发内存重分配）。
  • 重启实例（SHUTDOWN RESTART，彻底释放碎片，但需停服）。
• 避免大 Key / 热 Key 集中删除：用 UNLINK key 异步删除，减少内存空洞。

2. 内存使用率（Memory Utilization）

定义

• 指标：used_memory / maxmemory（建议控制在 70%~80%，预留空间应对突发流量）。
• 风险点：
  • 超过 maxmemory 且未配置淘汰策略时，会拒绝写请求。
  • 内存使用率过高可能导致碎片率上升（分配器难以找到连续内存块）。

监控方法

• 命令：INFO MEMORY 查看 used_memory 和 max_memory。
• 外部工具：Prometheus 监控 redis_memory_usage_percent 指标。

优化策略

• 配置淘汰策略（maxmemory-policy）
  • 生产首选：allkeys-lru（淘汰最近最少使用的 Key）。
  • 带过期时间场景：volatile-ttl（优先淘汰 TTL 短的 Key）。
• 大 Key 治理
  • 用 redis-cli --bigkeys 定位大 Key，拆解为小 Key（如分桶存储）。
  • 示例：用户数据按 ID 哈希分桶，避免单个 Hash 键存储数万字段。
• 冷热数据分离
  • 热数据（高频访问）保留在 Redis，冷数据迁移至数据库或分布式存储（如 HBase）。

3. 回收 Key（Key Eviction & Deletion）

自动回收（淘汰策略）

• 触发条件：内存达到 maxmemory 时，按策略删除 Key。
• 策略对比：

  策略	适用场景
  allkeys-lru	通用场景，无差别淘汰冷数据
  volatile-lru	仅淘汰带过期时间的冷数据
  allkeys-random	测试环境，随机淘汰
  noeviction	禁止淘汰（写满后拒绝请求）

手动回收（主动删除）

• 普通删除：DEL key（阻塞主线程，避免删除大 Key）。
• 异步删除：UNLINK key（4.0 + 版本支持，后台线程处理删除，不阻塞）。
• 批量删除：
  • 避免 KEYS * 遍历，用 SCAN 分批获取 Key 再删除：

    bash

    redis-cli --scan --pattern "prefix:*" | xargs -I {} redis-cli UNLINK {}
    

过期 Key 管理

• 定期删除：Redis 每秒随机检查少量 Key，发现过期则删除。
• 惰性删除：访问 Key 时检查是否过期，过期则删除。
• 内存泄漏排查：
  • 用 INFO STATS 查看 expired_keys（累计过期删除数），若长期为 0，可能未设置 TTL 或淘汰策略失效。
  • 检查业务代码是否遗漏设置 Key 过期时间（EXPIRE key seconds）。