这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天。
01. 什么是Redis
- 数据分冷热
- 将热数据存储到内存中
Redis基本工作原理
- 数据从内存中读写
- 数据保存到硬盘上防止重启数据丢失
- 增量数据保存到AOF文件中
- 全量数据RDB文件
- 单线程处理所有操作命令
String数据结构
- 可以存储 字符串、数字、二进制数据
- 通常和expire配合使用
- 场景：存储计数、Session
List数据结构Quicklist
Quicklist由一个双向链表和listpack实现
计数
一个用户有多项计数需求，可通过hash结构存储
Hash数据结构dict
- rehash：rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下，直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景，例如存有上百万的KV时，迁移过程将会明显阻塞用户请求。
- 渐进式rehash：为避免出现这种情况，使用了rehash方案。基本原理就是，每次用户访问时都会迁移少量数据。将整个迁移过程，平摊到所有的访问请求过程中。
zset数据结构zskiplist
限流
- 要求1秒内放行的请求为N，超过N则禁止访问
分布式锁
并发场景，要求一次只能有一个协程执行。执行完成后，其他等待中的协程才能执行。
可以使用redis的setnx实现，利用了两个特性：
- Redis时单线程执行命令
- setnx只有未设置过才能执行成功
03. Redis使用注意事项
1.大Key、热Key
String：value的字节数大于10KB即为大Key
Hash/Set/Zset/list等复杂数据结构类型：5000个或总value大于10MB
大Key的危害
- 读取成本高
- 容易导致慢查询（过期、删除）
- 主从复制异常，服务阻塞，无法正常相应请求
业务侧使用大Key的表现
- 请求Redis超时报错
消除大Key的方法
- 拆分
- 压缩
- 集合类结构hash、list、set、zset
（1）拆分：可以用hash取余、位掩码的方式决定放在哪个key中
（2）区分冷热：如榜单列表场景使用zset，之缓存前10页数据，后续数据走db
热Key的定义
用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。
热Key没有明确的标准，QPS超过500就有可能被识别为热Key
解决热Key的方法
- 设置Localcache：在访问Redis前，在业务服务测设置Localcache，降低访问Redis的QPS。LocalCache中缓存过期或未命中，则从Redis中将数据更新到LocalCache。Java的Guava、Golang的Bigcache就是这类LocalCache
- 拆分：将KV这一个热Key复制写入多分，例如KV1，KV2，访问的时候访问多个key，但value是同一个，以此将qps分散到不同实例上，降低负载。代价是，更新时需要更新多个key，存在数据短暂不一致的风险
- 使用Redis代理的热Key承载能力 字节跳动的Redis访问代理就具备热Key承载能力。本质上是结合了“热Key发现”、“LocalCache”两个功能。
2. 慢查询场景
容易导致redis慢查询的操作
3. 缓存穿透、缓存雪崩
缓存穿透：热点数据查询绕过缓存，直接查询数据库
缓存雪崩：大量缓存同时过期
如何减少缓存穿透
（1）缓存空值
（2）布隆过滤器：bitmap，只存key是否存在，只需占用极小的空间就能存储大量key值
如何避免缓存雪崩
（1）缓存空值：将缓存失效时间分散开
（2）使用缓存集群，避免单机宕机造成的缓存雪崩
