学习【Redis实战篇】这一篇就够了

程序员iteng

已于 2024-04-18 15:49:03 修改

阅读量871

点赞数 23

分类专栏： Redis 文章标签：学习 redis spring

于 2024-03-29 20:32:35 首次发布

本文链接：https://blog.csdn.net/weixin_44147535/article/details/137051458

版权

Redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1. 短信登录

1-1. 技术点

redis存储token

拦截器刷新token有效期

1-2. 业务

登录注册

2. 商户查询缓存

1-1. 技术点

缓存更新策略

在这里插入图片描述

缓存穿透

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

解决方案：

缓存空对象
布隆过滤器

缓存雪崩

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

解决方案：

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

缓存击穿

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

解决方案：

互斥锁：通过加互斥锁，只让一个业务线程重建缓存。其他线程要么等待锁的释放，然后重新查询缓存，要么直接返回空值。
- setnx
逻辑过期

1-2. 业务

查询缓存的商铺信息

3. 优惠卷秒杀

3-1. 技术点

全局唯一ID

在这里插入图片描述

全局唯一D生成策略：

UUID
Redis自增
snowflake算法
数据库自增

Redis自增ID策略：

每天一个key，方便统计订单量
ID构造是时间戳+计数器

乐观锁

版本号实现方案：在修改数据的时候，判断版本号是否和之前查询到的版本号一致。

cas实现方案：不再使用版本号，而是用查询出来的数据代替版本号。根据查询出来的数据再来判断是否可以进行修改，如果一致则可以修改。

基于Redis实现分布式锁

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

分布式锁的实现方案：

在这里插入图片描述

基于Redis的分布式锁实现思路：

利用set nx ex获取锁，并设置过期时间，保存线程标示
释放锁时先判断线程标示是否与自己一致，一致则删除锁。（编写lua脚本保证2个操作的原子性）

特性：

利用set nxi满足互斥性
利用set ex保证故障时锁依然能释放，避免死锁，提高安全性
利用Redis集群保证高可用和高并发特性

基于Redisson实现分布式锁

Redisson是一个基于Redis实现的分布式工具，它提供了一系列的分布式服务、分布式数据结构、分布式锁等。

Redisson分布式锁原理：

可重入：利用hash结构记录线程id和重入次数
可重试：利用信号量和发布订阅功能实现等待、唤醒，获取锁失败的重试机制
超时续约：利用watchDog（就是一个定时任务），每隔一段时间(releaseTime / 3)，重置锁的超时时间

Redisson实现可重入锁的原理

其实现原理和 JDK 的 ReentrantLock 类似。

实现原理：

1、尝试获取锁时

首先判断该锁是否存在，如果存在，再判断该锁是否是自己的，不是自己的则获取锁失败，如果是自己的，则将该锁的计数 + 1 并重置锁的有效期。利用hash结构记录线程id和可重入次数。
如果锁不存在，则成功获取锁，锁的计数 + 1，设置锁的有效期。

2、尝试释放锁时

首先判断该锁是否是自己的，如果不是自己的，则不用释放。
如果是自己获取的锁，则将该锁的计数 - 1。之后判断锁的计数是否为 0，如果为0，则释放锁，不为0，则重置锁的有效期。

分别用 lua 脚本来编写上面尝试获取锁和释放锁的语句，保证原子性。

在这里插入图片描述

Redisson实现锁重试和WatchDog机制的原理

锁重试

尝试获取锁时，首先判断锁的 ttl 是否过期，如果过期了，则获取锁成功。如果获取锁时没有设置锁的过期时间，则会开启 WatchDog（一个定时任务，定时刷新锁的过期时间）。
尝试获取锁时，锁还没有过期，则会订阅并等待锁的释放信息。
当释放锁时，会发布释放信息，并取消 WatchDog

WatchDog

一个定时任务，定时刷新锁的过期时间

在这里插入图片描述

Redisson的multiLock

原理：多个独立的Redis节点，必须在所有节点都获取重入锁，才算获取锁成功
缺陷：运维成本高、实现复杂

Redis消息队列实现异步秒杀

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

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

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

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

在这里插入图片描述

基于List的消息队列有哪些优缺点？

优点

利用Redis存储，不受限于JVM内存上限
基于Redis的持久化机制，数据安全性有保证
可以满足消息有序性

缺点：

无法避免消息丢失
只支持单消费者

基于PubSub的消息队列

在这里插入图片描述

基于PubSub的消息队列有哪些优缺点？

优点：

采用发布订阅模型，支持多生产、多消费

缺点：

不支持数据持久化
无法避免消息丢失
消息堆积有上限，超出时数据丢失

在这里插入图片描述

3-2. 业务

超卖问题

在这里插入图片描述

乐观锁实现方案：

版本号，修改数据的时候判断和之前查询的版本号是否一致。
CAS法，不再使用版本号，而是用查询出来的数据代替版本号。根据查询出来的数据再来判断是否可以进行修改，如果一致则可以修改。

在这里插入图片描述

一人一单问题

一人一单并发安全问题

在这里插入图片描述

调用lua脚本保证查询和删除锁原子性

调用RedisTemplate的execute方法来执行lua脚本
在这里插入图片描述

3-3. 小技巧

解决事务失效的3种方法

4. 达人探店

4-1. 技术点

利用Redis的SortedSet结构记录点赞的用户id，实现点赞排行榜

数据库返回按 list 集合顺序的元素

在这里插入图片描述

4-2. 业务

发布文章

文章点赞

只允许一人点一次赞

利用Redis的SortedSet结构记录点赞的用户id

点赞排行榜

将用户点赞的时间毫秒值作为 SortedSet 的 score，之后按 score 的顺序返回。

5. 好友关注

5-1. 技术点

利用 set 求交集获取共同关注好友

Feed流推送

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

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

在这里插入图片描述