1 为什么需要Redis
数据分冷热，将热数据存储到内存中
2 Redis应用案例
2.1 连续签到
2.1.1 String数据结构
- 可以存储字符串、数字、二进制数据
- 通常和expire配合使用
- 场景:存储计数、Session
2.2 消息通知
用list作为消息队列
使用场景:消息通知。
例如当文章更新时，将更新后的文章推送到ES，用户就能搜索到最新的文章数据
2.2.1 List数据结构Quicklist
由一个双向链表和listpack实现
2.2.2 Listpack数据结构
2.3 计数
2.3.1 Hash数据结构dict
- rehash: rehash操作是将ht[0]中的数据全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景,例如存有上百万的KV时，迁移过程将会明显阻塞用户请求。
- 渐进式rehash: 为避免出现这种情况，使用了rehash方案。基本原理就是,每次用户访问时都会迁移少量数据。将整个迁移过程，平摊到所有的访问用不请求过程中。
2.4 排行榜
积分变化时，排名要实时变更
2.4.1 zset数据结构zskiplist
2.5 限流
2.6 分布式锁
3 Redis使用注意事项
3.1 大key
3.1.1 定义
3.1.2 危害
- 读取成本高
- 容易导致慢查询(过期、删除)主从复制异常，服务阻塞
- 无法正常响应请求
3.1.3 业务侧使用大key的表现
请求Redis超时报错
3.1.4 消除大key的方法
拆分：
压缩：
将value压缩后写入redis，读取时解压后再使用。压缩算法可以是gzip、snappy、Iz4等。通常情况下,一个压缩算法压缩率高、则解压耗时就长。需要对实际数据进行测试后，选择一个合适的算法。如果存储的是JSON字符串，可以考虑使用MessagePack进行序列化。
集合类结构：
(1)拆分:可以用hash取余、位掩码的方式决定放在哪个key中
(2)区分冷热:如榜单列表场景使用zset，只缓存前10页数据，后续数据走db
3.2 热key
3.2.1 定义
用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。热key没有明确的标准，QPS 超过50O就有可能被识别为热Key
3.2.2 解决方法
设置Localcache：
在访问Redis前，在业务服务侧设置Localcache，降低访问Redis的QPS。LocalCache中缓存过期或未命中,则从Redis中将数据更新到LocalCache。Java的Guava、Golang的Biacache就是这类LocalCache
拆分：
将keyvalue这一个热Key复制写入多份，例如key1:value,key2:value，访问的时候访问多个key，但value是同一个以此将qps分散到不同实例上，降低负载。代价是，更新时需要更新多个key，存在数据短暂不一致的风险
使用Redis承载的热key代理能力：
字节跳动的Redis访问代理就具备热Key承载能力。本质上是结合了“热Key发现"、"LocalCache"两个功能
3.3 慢查询场景
3.4 缓存穿透、缓存雪崩
缓存穿透:热点数据查询绕过缓存，直接查询数据库
缓存雪崩:大量缓存同时过期
3.4.1 缓存穿透的危害
查询一个一定不存在的数据：
通常不会缓存不存在的数据,这类查询请求都会直接打到db，如果有系统bug或人为攻击，那么容易导致db响应慢甚至宕机
缓存过期时：
在高并发场景下，一个热key如果过期,会有大量请求同时击穿至db，容易影响db性能和稳定。
同一时间有大量key集中过期时，也会导致大量请求落到db上，导致查询变慢，甚至出现db无法响应新的查询
3.4.2 如何减少缓存穿透
缓存空值：
如一个不存在的userIlD。这个id在缓存和数据库中都不存在。则可以缓存一个空值，下次再查缓存直接反空值。
布隆过滤器：
通过bloom filter算法来存储合法Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值
3.4.3 如何避免缓存雪崩
缓存空值：
将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同Key过期时间，
可以设置为10分1秒过期，10分23秒过期,10分8秒过期。单位秒部分就是随机时间，这样过期时间就分散了。对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些。
使用缓存集群，避免单机宕机造成的缓存雪崩。
