这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
为什么需要Redis
-
数据从单表,演进出了分库分表,不同库表间的传输有瓶颈,出现了缓存需求
-
MySQL从单机演进出了集群
- 数据量增长
- 读写数据压力的不断增加
-
数据分冷热
- 热数据:经常被访问到的数据
-
将热数据存储到内存中
Redis应用案例
-
连续签到:每日签到
- 使用sds数据结构,可以存储字符串、数字、二进制数据
- 通常和expire配合使用
- 场景:存储技术、Session
-
消息通知:当文章更新时,将更新后的文章推送到ES,用户就能搜索到最新的文章数据
- 用list作为消息队列——quicklist
- quicklist由一个双向链表和listpack实现
-
计数:一个用户有多项计数需求,可以用hash
- hash数据结构dict
- rehash:rehash操作是将ht[0]中的数据,全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[0]拷贝到ht[1]速度是较快的。但是数据量较大时,迁移过程将会明显阻塞用户请求。
- 渐进式rehash:为避免出现这种情况,使用了rehash方案。基本原理就是,每次用户访问时都会迁移少量数据。将整个迁移过程,平摊到所有的访问用户请求过程中。
-
排行榜:积分变化时,排名要实时变更
-
结合dict后,可实现通过key操作跳表的功能
- XINCRBY myzset 2 “Alex”
- ZSCORE myzset “Alex”
-
zset数据结构zskiplist
-
-
限流:要求1秒内放行的请求为N,超过N则禁止访问
-
分布式锁:并发场景,要求一次智能有一个协程执行,执行完成后,其他等待中的协程才能执行
-
可以使用redis的setnx实现,利用了两个特性
- redis是单线程执行命令
- setnx只有未设置过才能执行成功
-
Redis注意事项
- 大Key:Value大于10KB就是大Key,使用大Key将导致Redis系统不稳定
- 热Key:一个Key的QPS特别高,将导致Redis实例出现负载突增,负责均衡流量不均的情况。导致单实例故障
- 慢查询:大Key、热Kye的读写;一次操作过多的Key(mset/hmset/sadd/zadd)
- 导致缓存穿透、缓存雪崩的场景及避免方案