这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
业务场景
1.连续签到
设置用户ID为key，然后设置过期时间，当24小时过期以后如果没有签到，那么就是0，所以就无法获取到之前的签到日期。
2.消息通知
用list作为消息队列，List数据结构Quicklist结构
Quicklist由一个双向链表和listpack实现
3.计数
一个用户有多项计数需求，可通过hash结构存储
4.排行榜
结合dick后，可以实现通过key操作跳表的功能
zset数据结构 zskiplist
5.限流
要求一秒内放行的请求为N，超过N则禁止访问
同样是string
6.分布式锁
并发场景，要求一次只能有一个协程执行，执行完成后，其他等待中的协程才能执行。
可以使用redis的setnx实现，利用两个特性
1.redis是单线程执行命令
2.setnx只有未设置过才能执行成功
但是这个方式知识体验setnx的特性，不是高可用的分布式锁实现。
该实现存在的问题：
1.业务超时解锁，导致并发问题。业务执行时间超过锁超时的时间
2.redis主备切临界点问题，主备切换后,A持有的锁还未同步到新的主节点时，B可在新主节点获取锁，导致并发问题
3.redis集群脑裂，导致出现多个主节点
Redis在业务中可能存在的问题
1、大key，热key
大key的定义
| 数据类型 | 大key的标准 |
|---|---|
| string | value的字节数大于10kb |
| Hash/set/Zset/list等复杂数据结构类型 | 元素个数大于5000个或总value字节数大于10Mb |
大key的危害
1.读取成本高
2.容易导致慢查询
3.主从复制异常，服务阻塞，无法正常响应请求
业务侧使用大key的表现
1.请求Redis超时报错
消除大key的方法
将大key拆分为小key，例如一个string拆分为多个string。
2.压缩
将value压缩后写入redis，读取时解压后在使用。压缩算法可以是gzip，snappy，lz4.
通常情况下，一个压缩算法压缩率搞，则解压耗时就长，需要对实际数据进行测试后，选择一个合适的算法。
如果是存储JSON字符串，可以使用MessagePack进行序列化
3.集合类结构hash，list，set
1.拆分，可以用hash区域，位掩码的方式决定放在那个key中
2.区分冷热：如榜单列表场景使用zset，只缓存前10页数据，后续数据走db
热key的定义
用户访问一个key的QPS特别高，导致server实例出现CPU负载突增导致不均的情况。热key没有明确的标准，QPS超过500就又可以被识别为热key
解决热key的方法
1.设置Localcache
在访问Redis前，业务服务侧设置Localcache，降低访问Redis的QPS。
Localcache中缓存过期或者未命中，则从Redis中将数据更新到LocalCache。java的Guava，Golang的Bigcache就是这类LoaclCache。
2.拆分
将key:value这一个热key复制写入多分，例如key1：value，key2：value，访问的时候访问多个key，但value是同一个，一次奖qps分散到不同实例上，降低负载。代价是，更新是需要更新多个key，存在数据短暂不一致的风险
2.使用Redis代理的热key承载能力
字节跳动的Redis访问代理就具备热Key承载能力。本质上是结合了“热Key发现”。“LocalCache”两个功能
慢查询场景
容易导致redis慢查询的操作
1.批量操作一次性传入过多的key/value，如mset/hmset/sadd/zadd等O（N）操作
2.zset大部分命令都是O（log(n)），当大小超过k以上时，简单的zadd、zrem也可能导致慢查询
3.操作的单个value过大，超过kb，也即，避免使用大key
4.对于大key的delete/expire操作也可能导致慢查询，redis4.0之前不支持异步删除unlink，大key删除会阻塞Redis
缓存穿透，缓存雪崩
缓存穿透：热点数据查询绕过缓存，直接查询数据库
缓存雪崩：大量缓存同时过期
