目录
[一、 前置知识点](#一、 前置知识点)
[1. 关系数据库与非关系型数据库](#1. 关系数据库与非关系型数据库)
[2. Redis 基础](#2. Redis 基础)
[(1)Redis 简介](#(1)Redis 简介)
[(2)Redis 安装部署](#(2)Redis 安装部署)
[3. Redis 命令工具](#3. Redis 命令工具)
[(1)redis-cli 命令行工具](#(1)redis-cli 命令行工具)
[(2)redis-benchmark 测试工具](#(2)redis-benchmark 测试工具)
[4. Redis 数据库常用命令](#4. Redis 数据库常用命令)
[二、Redis 持久化](#二、Redis 持久化)
[1. 持久化概述](#1. 持久化概述)
[2. 持久化分类](#2. 持久化分类)
[3. RDB 和 AOF 的区别](#3. RDB 和 AOF 的区别)
[4. RDB 和 AOF 的优缺点](#4. RDB 和 AOF 的优缺点)
[(1)RDB 优缺点](#(1)RDB 优缺点)
[(2)AOF 优缺点](#(2)AOF 优缺点)
[5. Redis 持久化配置](#5. Redis 持久化配置)
[(1)RDB 持久化配置](#(1)RDB 持久化配置)
[(2)AOF 持久化配置](#(2)AOF 持久化配置)
[6. AOF 重写](#6. AOF 重写)
[1. 内存碎片率(Mem Fragmentation Ratio)](#1. 内存碎片率(Mem Fragmentation Ratio))
[2. 内存使用率(Memory Utilization)](#2. 内存使用率(Memory Utilization))
[3. 回收 Key(Key Eviction & Deletion)](#3. 回收 Key(Key Eviction & Deletion))
[过期 Key 管理](#过期 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 安装部署
bash
--关闭防火墙
[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)配置参数
bash
--改配置
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 命令行工具
bash
--登录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 命令
bash
keys 命令符合规则的键值列表,通常情况可以结合*、?等选项来使用
keys * //查看当前数据库中所有键
keys v* //查看当前数据库中以v开头的数据
keys v? //查看当前数据库中以v开头后面包含任意一位的数据
keys v?? //查看当前数据中以v开头v开头后面包含任意两位的数据
exists 命令
bash
exists 命令可以判断键值是否存在
格式: exists 键名
例如:
exists teacher
(integer) 1 //表示 teacher 键是存在
(integer) 0 //表示 tea 键不存在
del 命令
bash
del 命令可以删除当前数据库的指定 key
keys *
del 指定键
type 命令
bash
type 命令可以获取key对应的value值类型
rename 命令
bash
rename 命令是对已有key进行重命名
命令格式:rename 源key 目标key
例如:rename v22 v2
容易出错若出现同名则会覆盖
可以使用exists先检查是否存在,或者renamenx
renamenx 命令
bash
renamenx : 可检测目标(新名)是否存在,避免冲突覆盖,存在则不进行
dbsize 命令
bash
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 持久化配置
bash
# 触发规则: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 持久化配置
bash
# 启用 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
)
关键步骤:
-
主进程 fork 子进程
-
子进程遍历内存数据生成新 AOF 文件
-
主进程将重写期间的增量命令写入缓冲区
-
子进程完成时,主进程追加缓冲区命令到新文件
-
原子替换旧 AOF 文件
重写配置优化
bash
# 重写期间是否禁用 fsync(提升性能但可能丢失数据)
no-appendfsync-on-rewrite yes
# 重写触发阈值(默认文件增长100%且大于64MB)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
三、性能管理
bash
redis-cli //登录数据库
info memory //查看redis 使用内存值
bash
回收策略(文件中带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
)。
- 用