这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天，本次对于大厂如何使用redis进行了了解和学习，对于一些场景的分析，权衡了redis的优缺点，并分析了如何解决。
redis的使用：
- 数据从单表，演进出了分库分表
- MySQL从单击演进出了集群（导致数据量增长，读写数据压力不断增加）
- 数据分冷热（需要把经常被访问到的数据，即热数据，存储到内存中）
redis基本原理：
- 数据从内存中读写
- 数据保存到硬盘上防止重启数据丢失（增量数据保存到AOF文件、全量数据保存到RDB文件
- 单线程处理所有操作命令
Hash数据结构dict
- rehash：rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下，直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景下，迁移过程会明显阻塞用户请求。
- 渐进式rehash：每次用户访问时都会迁移少量数据。将整个迁移过程，平摊到所有的访问用不请求过程。
redis使用时可能出现的问题：
大Key
大Key定义：
- String类型-----value的字节数大于10KB
- Hash/Set/Zset/list等复杂数据结构类型----元素个数大于5000个或总value字节数大于10MB
大Key危害---导致请求redis超时报错：
- 读取成本高
- 容易导致慢查询（过期、删除）
- 主从复制异常，服务阻塞，无法正常相应请求
消除大Key的方法：
- 拆分----将大Key拆分为小Key
- 压缩---将value压缩后写入redis，读取时解压再使用（压缩效率高，解压耗时长，需要选择合理压缩算法）
- 集合类结构hash、list、set进行拆分：用hash取余、位掩码的方式决定放在哪个key中
- 集合类结构hash、list、set区分冷热
热Key：
热Key定义：用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况，热Key无明确标准。
消除热Key方法：
- 在访问redis之前，在业务服务侧设置localcache，降低访问Redis的QPS
- 进行拆分，将key:value这一个热Key复制写入多份，访问的时候访问多个Key，但value是同一个，因此将qps分散到不同实例中，降低负载。（更新时需要更新多个key，存在可能数据短暂不一致）
- 使用redis代理的rekey承载能力
容易导致redis慢查询的操作：
- 批量操作一次性传入过多的key/value（建议单批次不要超过100，否则性能下降明显）
- zset大部分命令都是O(log(n)),大小超过5K以上
- 对大Key的delete/expire操作
缓存穿透：
热点数据查询绕过缓存，直接查询数据库
危害：如果查询一个一定不存在的数据，这类查询请求会直接到db，如果人为攻击或者系统bug容易导致db响应慢或者宕机。如果在高并发场景下，一个热key过期，就会有大量请求同时击穿到db，容易影响db性能和稳定。如果在同一时间由大量key集中过期，也会有大量请求落到db上，导致查询变慢。
减少缓存穿透的方法：
- 缓存空值
- 布隆过滤器
缓存雪崩：大量缓存同时过期
避免缓存雪崩：
- 缓存空值
- 使用缓存集群
