Redis黑马版

李阳2025-09-082025-09-15

一、Redis安装

1. 指定配置启动

如果要让Redis以后台方式启动，则必须修改Redis配置文件，就在我们之前解压的redis安装包下（/usr/local/src/redis-6.2.6），名字叫redis.conf：

我们先将这个配置文件备份一份：

cp redis.conf redis.conf.bck

然后修改redis.conf文件中的一些配置：

# 允许访问的地址，默认是127.0.0.1，会导致只能在本地访问。修改为0.0.0.0则可以在任意IP访问，生产环境不要设置为0.0.0.0
bind 0.0.0.0
# 守护进程，修改为yes后即可后台运行
daemonize yes 
# 密码，设置后访问Redis必须输入密码
requirepass 123321

Redis的其它常见配置：

# 监听的端口
port 6379
# 工作目录，默认是当前目录，也就是运行redis-server时的命令，日志、持久化等文件会保存在这个目录
dir .
# 数据库数量，设置为1，代表只使用1个库，默认有16个库，编号0~15
databases 1
# 设置redis能够使用的最大内存
maxmemory 512mb
# 日志文件，默认为空，不记录日志，可以指定日志文件名
logfile "redis.log"

启动Redis：

# 进入redis安装目录 
cd /usr/local/src/redis-6.2.6
# 启动
redis-server redis.conf

停止服务：

# 利用redis-cli来执行 shutdown 命令，即可停止 Redis 服务，
# 因为之前配置了密码，因此需要通过 -u 来指定密码
redis-cli -u 123321 shutdown

1.3.3.开机自启

我们也可以通过配置来实现开机自启。

首先，新建一个系统服务文件：

vi /etc/systemd/system/redis.service

内容如下：

[Unit]
Description=redis-server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/redis-server /usr/local/src/redis-6.2.6/redis.conf
PrivateTmp=true

[Install]
WantedBy=multi-user.target

然后重载系统服务：

systemctl daemon-reload

现在，我们可以用下面这组命令来操作redis了：

# 启动
systemctl start redis
# 停止
systemctl stop redis
# 重启
systemctl restart redis
# 查看状态
systemctl status redis

执行下面的命令，可以让redis开机自启：

systemctl enable redis

2.Redis客户端

安装完成Redis，我们就可以操作Redis，实现数据的CRUD了。这需要用到Redis客户端，包括：

命令行客户端
图形化桌面客户端
编程客户端

2.1 Redis命令行客户端

Redis安装完成后就自带了命令行客户端：redis-cli，使用方式如下：

redis-cli [options] [commonds]

其中常见的options有：

-h 127.0.0.1：指定要连接的redis节点的IP地址，默认是127.0.0.1
-p 6379：指定要连接的redis节点的端口，默认是6379
-a 123321：指定redis的访问密码

其中的commonds就是Redis的操作命令，例如：

ping：与redis服务端做心跳测试，服务端正常会返回pong

不指定commond时，会进入redis-cli的交互控制台：

2.2 通用命令

通用指令是部分数据类型的，都可以使用的指令，常见的有：

KEYS：查看符合模板的所有key
DEL：删除一个指定的key
EXISTS：判断key是否存在
EXPIRE：给一个key设置有效期，有效期到期时该key会被自动删除
TTL：查看一个KEY的剩余有效期

通过help [command] 可以查看一个命令的具体用法，例如：

# 查看keys命令的帮助信息：
127.0.0.1:6379> help keys

KEYS pattern
summary: Find all keys matching the given pattern
since: 1.0.0
group: generic

2.3 String类型

String类型，也就是字符串类型，是Redis中最简单的存储类型。

其value是字符串，不过根据字符串的格式不同，又可以分为3类：

string：普通字符串
int：整数类型，可以做自增、自减操作
float：浮点类型，可以做自增、自减操作

不管是哪种格式，底层都是字节数组形式存储，只不过是编码方式不同。字符串类型的最大空间不能超过512m.

2.2.1.String的常见命令

String的常见命令有：

SET：添加或者修改已经存在的一个String类型的键值对
GET：根据key获取String类型的value
MSET：批量添加多个String类型的键值对
MGET：根据多个key获取多个String类型的value
INCR：让一个整型的key自增1
INCRBY:让一个整型的key自增并指定步长，例如：incrby num 2 让num值自增2
INCRBYFLOAT：让一个浮点类型的数字自增并指定步长
SETNX：添加一个String类型的键值对，前提是这个key不存在，否则不执行
SETEX：添加一个String类型的键值对，并且指定有效期

2.2.2 Key类型

Redis没有类似MySQL中的Table的概念，我们该如何区分不同类型的key呢？

例如，需要存储用户、商品信息到redis，有一个用户id是1，有一个商品id恰好也是1，此时如果使用id作为key，那就会冲突了，该怎么办？

我们可以通过给key添加前缀加以区分，不过这个前缀不是随便加的，有一定的规范：

Redis的key允许有多个单词形成层级结构，多个单词之间用’:’隔开，格式如下：

项目名:业务名:类型:id

这个格式并非固定，也可以根据自己的需求来删除或添加词条。这样以来，我们就可以把不同类型的数据区分开了。从而避免了key的冲突问题。

例如我们的项目名称叫 heima，有user和product两种不同类型的数据，我们可以这样定义key：

user相关的key：heima:user:1
product相关的key：heima:product:1

如果Value是一个Java对象，例如一个User对象，则可以将对象序列化为JSON字符串后存储：

KEY	VALUE
heima:user:1	{“id”:1, “name”: “Jack”, “age”: 21}
heima:product:1	{“id”:1, “name”: “小米11”, “price”: 4999}

并且，在Redis的桌面客户端中，还会以相同前缀作为层级结构，让数据看起来层次分明，关系清晰：

2.4 Hash类型

Hash类型，也叫散列，其value是一个无序字典，类似于Java中的HashMap结构。

String结构是将对象序列化为JSON字符串后存储，当需要修改对象某个字段时很不方便（要删除更新插入）：

Hash结构可以将对象中的每个字段独立存储，可以针对单个字段做CRUD：

Hash的常见命令有：

HSET key field value：添加或者修改hash类型key的field的值
HGET key field：获取一个hash类型key的field的值
HMSET：批量添加多个hash类型key的field的值
HMGET：批量获取多个hash类型key的field的值
HGETALL：获取一个hash类型的key中的所有的field和value
HKEYS：获取一个hash类型的key中的所有的field
HINCRBY:让一个hash类型key的字段值自增并指定步长
HSETNX：添加一个hash类型的key的field值，前提是这个field不存在，否则不执行

eg：

127.0.0.1:6379> Hset heima:user:2 name Rose
(integer) 1
127.0.0.1:6379> Hset heima:user:2 age 18
(integer) 1
127.0.0.1:6379>

eg2:

127.0.0.1:6379> HMSET heima:user:3 name LiLei age 20 sex man
OK
127.0.0.1:6379> HMGET heima:user:3 name age sex
1) "LiLei"
2) "20"
3) "man"

2.5.List类型

Redis中的List类型与Java中的LinkedList类似，可以看做是一个双向链表结构。既可以支持正向检索和也可以支持反向检索。(评论，点赞)

特征也与LinkedList类似：

有序
元素可以重复
插入和删除快
查询速度一般

常用来存储一个有序数据，例如：朋友圈点赞列表，评论列表等。

List的常见命令有：

LPUSH key element … ：向列表左侧插入一个或多个元素
LPOP key：移除并返回列表左侧的第一个元素，没有则返回nil
RPUSH key element … ：向列表右侧插入一个或多个元素
RPOP key：移除并返回列表右侧的第一个元素
LRANGE key star end：返回一段角标范围内的所有元素
BLPOP和BRPOP：与LPOP和RPOP类似，只不过在没有元素时等待指定时间，而不是直接返回nil

2.6.Set类型

Redis的Set结构与Java中的HashSet类似，可以看做是一个value为null的HashMap。因为也是一个hash表，因此具备与HashSet类似的特征：

无序
元素不可重复
查找快
支持交集、并集、差集等功能

Set的常见命令有：

SADD key member … ：向set中添加一个或多个元素
SREM key member … : 移除set中的指定元素
SCARD key：返回set中元素的个数
SISMEMBER key member：判断一个元素是否存在于set中
SMEMBERS：获取set中的所有元素
SINTER key1 key2 … ：求key1与key2的交集

例如两个集合：s1和s2:

求交集：SINTER s1 s2

求s1与s2的不同：SDIFF s1 s2

练习：

将下列数据用Redis的Set集合来存储：

张三的好友有：李四、王五、赵六
李四的好友有：王五、麻子、二狗

利用Set的命令实现下列功能：

计算张三的好友有几人
计算张三和李四有哪些共同好友
查询哪些人是张三的好友却不是李四的好友
查询张三和李四的好友总共有哪些人
判断李四是否是张三的好友
判断张三是否是李四的好友
将李四从张三的好友列表中移除

2.7.SortedSet类型

Redis的SortedSet是一个可排序的set集合，与Java中的TreeSet有些类似，但底层数据结构却差别很大。SortedSet中的每一个元素都带有一个score属性，可以基于score属性对元素排序，底层的实现是一个跳表（SkipList）加 hash表。

SortedSet具备下列特性：

可排序
元素不重复
查询速度快

因为SortedSet的可排序特性，经常被用来实现排行榜这样的功能。

SortedSet的常见命令有：

ZADD key score member：添加一个或多个元素到sorted set ，如果已经存在则更新其score值
ZREM key member：删除sorted set中的一个指定元素
ZSCORE key member : 获取sorted set中的指定元素的score值
ZRANK key member：获取sorted set 中的指定元素的排名
ZCARD key：获取sorted set中的元素个数
ZCOUNT key min max：统计score值在给定范围内的所有元素的个数
ZINCRBY key increment member：让sorted set中的指定元素自增，步长为指定的increment值
ZRANGE key min max：按照score排序后，获取指定排名范围内的元素
ZRANGEBYSCORE key min max：按照score排序后，获取指定score范围内的元素
ZDIFF、ZINTER、ZUNION：求差集、交集、并集

注意：所有的排名默认都是升序，如果要降序则在命令的Z后面添加REV即可，例如：

升序获取sorted set 中的指定元素的排名：ZRANK key member
降序获取sorted set 中的指定元素的排名：ZREVRANK key memeber

练习题：

将班级的下列学生得分存入Redis的SortedSet中：

Jack 85, Lucy 89, Rose 82, Tom 95, Jerry 78, Amy 92, Miles 76

并实现下列功能：

删除Tom同学
获取Amy同学的分数
获取Rose同学的排名
查询80分以下有几个学生
给Amy同学加2分
查出成绩前3名的同学
查出成绩80分以下的所有同学

二、实战篇

1. 短信登录

1.1 缓存

1.1.1 缓存更新策略

1.1.2 缓存穿透

缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。

常见解决方式：

缓存空对象（将空数据缓存起来）
- 优点：实现简单，维护方便
- 缺点：
  1. 造成额外消耗（可以设置很短的有效期，这样不会带来特别大的内存消耗，短期的垃圾数据能识别）
  2. 可能造成短期的不一致
布隆过滤（在客户端与Redis中间插入布隆过滤器，当请求传入时，先去请求布隆过滤器，当不存在时直接拒绝，存在时才会去Redis中查询）
- 优点：内存占用少，没有多余Key
- 缺点：实现复杂，存在误判

1.1.3 缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方法：

给不同的Key的TTL添加随机值
利用Redis集群提高服务的可用性
给缓存业务添加降级限流策略
给业务添加多级缓存

1.1.4 缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

常见解决方案：

互斥锁
逻辑过期

2. 超卖问题

2.1 悲观锁与乐观锁

悲观锁：认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。

乐观锁：认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。

如果没有修改则认为是安全的，自己才更新数据。
如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。

2.1.1 乐观锁

版本号法：

当有多线程时第一个线程先查询版本号（1），假设来了第二个线程也在这时查询了版本号（1），线程1先扣减库存，并且将版本号+1，只有在版本号为与查询到的版本号一致时才执行，这时线程2更新时发现版本变成了2，就无法完成更新

CSA方法：

与版本号法思路一致

2.2 分布式锁

分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。

	MySQL	Redis	Zookeeper
互斥	利用mysql本身的互斥锁机制	利用setnx这样的互斥命令	利用节点的唯一性和有序性实现互斥
高可用	好	好	好
高性能	一般	好	一般
安全性	利用节点的唯一性和有序性实现互斥	利用节点的唯一性和有序性实现互斥	临时节点，断开连接自动释放

基于Redis的分布锁

实现分布式锁时需要实现的两个基本方法:

获取锁︰

·互斥:确保只能有一个线程获取锁

#添加锁，利用setnx的互斥特性,NX是互斥，EX是设置超时时间

SETNX lock thread1 NX EX 10

释放锁:
- ·手动释放
- ·超时释放:获取锁时添加一个超时时间
  #释放锁，删除即可
  DEL key

Redisson

Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid)。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。

Redisson分布式锁解决主从一致的问题

面试题：Redisson的分布式锁为什么使用Lua脚本实现而不是使用事务？

原子性更强：Lua 脚本作为整体执行，中间不会被打断，确保复杂锁逻辑（如判断 + 操作）的原子性；事务是 “最终一致性”，可能被插入其他命令。
支持复杂逻辑：可包含条件判断、循环等，满足锁的判断归属、续约等需求；事务仅能批量执行命令，无逻辑处理能力。
减少网络交互：使用 Lua 脚本可以将多个命令打包成一个请求发送到 Redis，大幅减少客户端与 Redis 服务器之间的网络往返次数，提升性能；事务实现相同逻辑需更多网络通信。
安全释放锁：释放锁时需要先判断锁是否属于当前线程，再执行删除操作。这个 “判断 - 删除” 的过程必须原子化，否则可能误删其他线程的锁。用 Lua 脚本可以轻松实现这一点，而事务难以保证这种条件操作的原子性。

3. 优惠券秒杀

3.1 Redis消息队列

消息队列(Message Queue)，字面意思就是存放消息的队列。最简单的消息队列模型包括3个角色:

消息队列:存储和管理消息，也被称为消息代理(Message Broker)
生产者:发送消息到消息队列
消费者:从消息队列获取消息并处理消息

Redis提供了三种不同的方式来实现消息队列:

list结构:基于List结构模拟消息队列
PubSub:基本的点对点消息模型
Stream:比较完善的消息队列模型

List结构的消息队列

队列是入口和出口不在一边，因此我们可以利用:LPUSH结合RPOP、或者RPUSH结合LPOP来实现。不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。

PubSub结构的消息队列

PubSub(发布订阅）是Redis2.0版本引入的消息传递模型。顾名思义，消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

SUBSCRIBE channel [channel]:订阅一个或多个频道
PUBLISH channel msg :向一个频道发送消息
PSUBSCRIBE pattern[pattern]:订阅与pattern格式匹配的所有频道

Stream的消息队列

Stream是 Redis 5.0引入的一种新数据类型，可以实现一个功能非常完善的消息队列。

Stream消息队列-消费组

消费者组(Consumer Group)∶将多个消费者划分到一个组中，监听同一个队列。具备下列特点:

创建消费者组

其他命令：

从消费者组读取信息：

总结

4. Feed流

Feed流产品有两种常见模式:

Timeline:不做内容筛选，简单的按照内容发布时间排序，常用于好友或关注。例如朋友圈
- 优点:信息全面，不会有缺失。并且实现也相对简单
- 缺点:信息噪音较多，用户不一定感兴趣，内容获取效率低
智能排序:利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户
- 优点:投喂用户感兴趣信息，用户粘度很高，容易沉迷
- 缺点:如果算法不精准，可能起到反作用

4.1 TimeLine模式

5. GEO数据结构

GEO就是Geolocation的简写形式，代表地理坐标。Redis在3.2版本中加入了对GEO的支持，允许存储地理坐标信息，帮助我们根据经纬度来检索数据。常见的命令有:

GEOADD:添加一个地理空间信息，包含:经度（longitude)、纬度(latitude)、值(member)

GEODIST:计算指定的两个点之间的距离并返回

GEOHASH:将指定member的坐标转为hash字符串形式并返回

GEOPOS:返回指定member的坐标

GEORADIUS:指定圆心、半径，找到该圆内包含的所有member，并按照与圆心之间的距离排序后返回。6.2以后已废弃

GEOSEARCH:在指定范围内搜索member，并按照与指定点之间的距离排序后返回。范围可以是圆形或矩形。6.2.新功能

GEOSEARCHSTORE :与GEOSEARCH功能一致，不过可以把结果存储到一个指定的key。6.2.新功能

GEOADD g1 116.378248 39.865275 bjn 116.42803 39.903738 bjz 116.322287 39.893729 bjx

6. BitMap

把每一个bit位对应当月的每一天，形成了映射关系。用O和1标示业务状态，这种思路就称为位图(BitMap)

Redis中是利用string类型数据结构实现BitMap，因此最大上限是512M，转换为bit则是2^32个bit位。

BitMap用法

BitMap的操作命令有:

SETBIT:向指定位置（offset)存入一个0或1
GETBIT:获取指定位置( offset)的bit值
BITCOUNT:统计BitMap中值为1的bit位的数量
BITFIELD:操作（查询、修改、自增）BitMap中bit数组中的指定位置（offset)的值
BITFIELD_RO:获取BitMap中bit数组，并以十进制形式返回
BITOP∶将多个BitMap的结果做位运算(与、或、异或)
BITPOS:查找bit数组中指定范围内第一个0或1出现的位置