NoSQL 之 Redis 配置与优化

目录

[一、 前置知识点](#一、 前置知识点)

[1. 关系数据库与非关系型数据库](#1. 关系数据库与非关系型数据库)

(1)关系型数据库

(2)非关系型数据库

(3)非关系型数据库产生背景

(4)两者对比

[2. Redis 基础](#2. Redis 基础)

[(1)Redis 简介](#(1)Redis 简介)

[(2)Redis 安装部署](#(2)Redis 安装部署)

(3)配置参数

[3. Redis 命令工具](#3. Redis 命令工具)

[(1)redis-cli 命令行工具](#(1)redis-cli 命令行工具)

[(2)redis-benchmark 测试工具](#(2)redis-benchmark 测试工具)

[4. Redis 数据库常用命令](#4. Redis 数据库常用命令)

(1)命令

(2)多数据库常用命令

[二、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

关键步骤

  1. 主进程 fork 子进程

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

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

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

  5. 原子替换旧 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_memorymax_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)。
相关推荐
一心0921 小时前
ubuntu 20.04.6 sudo 源码包在线升级到1.9.17p1
运维·ubuntu·sudo·漏洞升级
好好学习啊天天向上1 小时前
世上最全:ubuntu 上及天河超算上源码编译llvm遇到的坑,cmake,ninja完整过程
linux·运维·ubuntu·自动性能优化
你想考研啊1 小时前
三、jenkins使用tomcat部署项目
运维·tomcat·jenkins
好奇的菜鸟2 小时前
如何在IntelliJ IDEA中设置数据库连接全局共享
java·数据库·intellij-idea
tan180°2 小时前
MySQL表的操作(3)
linux·数据库·c++·vscode·后端·mysql
代码老y2 小时前
Docker:容器化技术的基石与实践指南
运维·docker·容器
满昕欢喜2 小时前
SQL Server从入门到项目实践(超值版)读书笔记 20
数据库·sql·sqlserver
典学长编程2 小时前
Linux操作系统从入门到精通!第二天(命令行)
linux·运维·chrome
wuk9983 小时前
基于MATLAB编制的锂离子电池伪二维模型
linux·windows·github
Hello.Reader4 小时前
Redis 延迟排查与优化全攻略
数据库·redis·缓存