Redis基础知识整理

最新推荐文章于 2025-10-29 09:30:00 发布

原创最新推荐文章于 2025-10-29 09:30:00 发布 · 1.5k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#redis #java #linux

数据库专栏收录该内容

1 篇文章

订阅专栏

本文详细介绍了Redis的基础知识，包括其特点作用、支持的数据类型如String、Hash、List、Set和zset，以及持久化机制的RDB和AOF。此外，还讨论了Redis的事务、常见架构模式如单机、主从、哨兵和集群，并列举了Redis在会话缓存、排行榜、发布订阅和分布式锁等场景的应用。最后，针对缓存击穿、穿透和雪崩问题提出了解决方案。

redis基础知识点

一、什么是redis及特点作用

Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库。

redis运行在内存中但是可以持久化到磁盘，所以它支持高速读写，及数据持久化。
redis支持复杂的数据结构储存。
redis支持数据备份，即master-slave模式的数据备份。所以可以运用主从复制实现读写分离

二、redis支持的数据类型

redis不仅支持key-value类型的数据，还支持其他复杂的数据类型。
redis主要支持的数据类型有5种：
String字符串，Hash哈希，List列表，Set集合，zset有序集合（sorted set）。

String字符串
string 类型是二进制安全的。 string 可以包含任何数据。比如jpg图片或者序列化的对象。
string 类型是 redis 最基本的数据类型，string 类型的值最大能存储 512MB。

#set 设置值
set key value
#get 取值
get value

Hash哈希
hash 是一个键值(key=>value)对集合。
hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

# 如果key 被用过，需删除
del key
# hash 设置值
hmset key key1 value1 key2 value2
# hash 取值
hget key key1/key2

List列表
list 是简单的字符串列表，按照插入顺序排序。添加一个元素到列表的头部（左边）或者尾部（右边）。

# 如果有其他类型key，需删除，否则报错
del key
# list 设置值 
lpush key value1  //lpush头部添加，可以多次value设置
# list 取值
lrange key 0 10   //0 ,10 是范围

Set集合
set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

# 如果有其他类型key，需删除，否则报错
del key
# set 设置值
sadd key value1   //可以多次value设置
# set 取值
smembers key

zset有序集合
zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。

# 如果有其他类型key，需删除，否则报错
del key
# zset 设置值
zadd key 0 value1 //可以多次value设置; 0 是分数（次数），可重复
# zset 取值
zrangebyscore key 0 10  //通过分数排序去 0~10 之间的值

附：redis指令测试练习工具

redis指令测试练习工具

三、redis持久化

Redis 提供了两种持久化方式:RDB （Redis DataBase）（默认）和 AOF （Append Only File）。
ps : 持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

1、RDB

在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。redis 重启会通过加载dump.rdb文件恢复数据。

附：
redis.conf 配置文件中RDB持久化配置信息：

# RDB 持久化，快照保存频率
# 900秒内，如果超过1个key被修改，则发起快照保存
# 300秒内，如果超过10个key被修改，则发起快照保存
# 60秒内，如果1万个key被修改，则发起快照保存
save 900 1
save 300 10
save 60 10000

# 启用rdb文件压缩手段，默认为yes。
rdbcompression yes

2、AOF

Redis 默认不开启。是以文件形式存储。
它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。
redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

附：
redis.conf 配置文件中AOF持久化配置信息：

# 开启 AOF 持久化
appendonly yes

RDB 与 AOF对比
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
Redis 做缓存，可以关闭持久化。

四、redis事务

1、什么是redis事务

redis事务是一组命令集合，1.开启事务可以一次执行多条命令，一条事务中的所有命令会被序列化。
2.其他客户端提交的命令请求不会插入到事务执行命令序列中。

2、redis事务过程

开始事务
入命令列（被序列化，按顺序执行）
执行事务

3、redis事务命令

注：不分大小写

# 1、开启一个事务
MULTI
# 2、执行事务
EXEC
# 3、放弃事务：客户端取消事务队列，退出事务
DISCARD
# 4、监控 一个或多个key,若其中一个key被修改，则事务不执行。
#   监控一直持续到EXEC命令结束
WATCH key [key ...]

4、redis事务注意示例

事务队列存在错误命令，则EXEC执行事务，所有队列命令不成功
事务队列存在语法性错误，则EXEC执行事务，队列中正确的命令执行有效 ===> 说明 redis事务不回滚
WATCH 监控某个key ,开启事务期间，若该key被其他客户端修改，则执行EXEC不成功。

附：事务的基本操作：在这里插入图片描述

五、redis架构模式

单机模式
特点：操作简单，易理解。
不足：1、内存容量有限 2、处理能力有限 3、无法高可用。
主从模式
特点：服务器分为两类角色：master（主服务器，一般负责写）；slave（从服务器，一般负责读）。可实现读写分离。
不足：1、无法保证高可用；2、没有解决 master 写的压力
哨兵
特点：sentinel 分布式监控：master和slave；出现问题时：1.提醒通知，2.自动故障迁移.
不足：1、主从模式，切换需要时间丢数据；2、没有解决 master 写的压力
集群模式
1、Sentinel 高可用集群，主从复制，故障转移
2、Cluster 高可用集群，配置简单，支持故障转移，动态增减节点，水平横向扩展（推荐）

架构分析：有图可以帮你更好的理解
Redis系统架构详解
架构具体实现：
Redis 系列文章导读

六、redis运用场景

会话缓存

会话缓存是在项目中最常见的运用方式。redis做会话缓存（session cache），可以缓存一些用户常用信息和历史信息，再次访问时可以直接访问redis中的数据，速度很快，加强了用户体验

排行榜相关问题

内存中对数字进行递增或递减的操作实现快，redis提供的集合（Set）和有序集合（Sorted Set）数据结构可以有效对排名等问题的快速处理。

redis发布订阅

redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

分布式锁

运用背景：
        分布式锁：在分布式环境中，多个进程的同步访问临界资源，为了让其有序的访问某种临界资源，防止“脏数据”，用分布式锁解决该类问题。
现实解决：
        一般为了实现分布式锁，可以用zookeeper或 redis 作为具体的实现方式。（这里主要说redis）
        redis一般做缓存数据库，可以加快访问数据的速度。但也可以在分布式应用中用来实现分布式锁。1.在客户端访问目标资源时，有redis数据库控制访问权限（通过加锁，解锁）2. 通过加锁 setNX,解锁del,锁超时expire等设置实现有序的访问数据库资源。

七、redis 缓存击穿，缓存穿透，雪崩及解决方案

1、缓存击穿

缓存击穿：某个key很热点，访问量很大，处于高并发的访问状态。当遇到key值过期等情况，则失效的瞬间，持续的并发击穿缓存，直接访问DB，造成数据压力大崩溃。
特点：单个key 引起的高并发
解决：1.事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
2、事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL 被打死。
3、事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

2、缓存穿透

缓存穿透：缓存和数据库都没有该数据，用户不断发起请求，缓存查不到，会不断的请求数据库，导致数据库压力过大，严重会击垮数据库。
例子：黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。
举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。
解决：数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

3、雪崩

雪崩： redis 突然宕机等情况，大量的key值失效，高并发的请求直接访问DB，导致DB压力大，甚至宕机，重启会再次宕机。
解决：1.事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
2、事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL 被打死。
3、事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

参考文档：
redis菜鸟教程

Redis 持久化之RDB和AOF