这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天，今天学习了非关系型数据库Redis，这是我第一次接触非关系数据库，下面是我的收获
Redis
1.1 什么是Redis
1.1.1 为什么需要Redis
原因
- 数据从单表演进到分库分表
- MySql数据库从单机演进出了集群，即数据量不断增长，读写数据压力也不断增加
- 数据分冷数据和热数据，即经常被访问到的数据被称为热数据
- 需要将热数据存储到内存中，便于读写
1.1.2 工作原理
- 数据从内存中读写
- 数据保存到硬盘上防止重启数据时，数据丢失
- 增量数据保存到AOF文件
- 全量数据RDB文件
- 单线程处理所有操作命令
1.2 应用案例
下面举例一个课程提到的案例
分布式锁
场景：在并发环境下，要求一次只能有一个协程执行，且执行完成后，其他等待中的协程才能执行
使用Redis的解决方法：
使用Redis的setnx实现，利用其两个特性
- Redis是单线程执行命令（上文工作原理提到过）
- setnx只有未设置过才能执行成功
1.3 注意事项
1.3.1 大Key & 热Key
大Key
数据类型：String
大Key标准：value的字节数大于10KB即为大Key
数据类型：Hash/Set/Zset/list等复杂数据结构类型
大Key标准：元素个数大于5000个或总value字节数大于10MB即为大Key
危害
- 读取成本高
- 容易导致慢查询（过期、删除）
- 主从复制异常，服务阻塞，无法正常响应请求
消除大Key的方法
-
拆分
将大Key拆分为小Key，例如一个String拆分为多个String
-
压缩
将value压缩后写入Redis，读取时解压后再使用
-
集合类结构hash，list、set
- 拆分，可以用hash取余、位掩码的方式决定放在哪个Key中
- 区分冷热，如榜单列表场景使用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
- 拆分
将key:value这一个热Key复制写入多份，例如key1:value，key2:value，访问的时候访问多个key，但value是同一个，以此将qps分散到不同实例上，降低负载。代价是，更新时需要更新多个key,存在数据短暂不一致的风险
- 使用Redis代理的热Key承载能力
字节的Redis访问代理就具备热Key承载能力，具体的不做介绍
1.3.2 慢查询场景
容易导致Redis慢查询的操作
- 批量操作一次性传入过多的key/value，如mset/hmset/sadd/zadd等O(n)操作
- zset大部分命令都是O(log(n))，当大小超过5k以上时，简单的zadd/zrem也可能导致慢查询
- 操作的单个value过大，超过10KB。也即，避免使用大Key
- 对大key的delete/expire操作也可能导致慢查询,Redis4.0之前不支持异步删除unlink，大key删除会阻塞Redis
1.3.3 缓存穿透、雪崩
缓存穿透：热点数据查询绕过缓存，直接查询数据库
缓存雪崩：大量缓存同时过期
危害
- 查询一个一定不存在的数据
通常不会缓存不存在的数据，这类查询请求都会直接打到db，如果有系统bug或人为攻击，那么容易导致db响应慢甚至宕机
- 缓存过期时
在高并发场景下，一个热key如果过期，会有大量请求同时击穿至db，容易影响db性能和稳定 同一时间有大量key集中过期时，也会导致大量请求落到db上，导致查询变慢，甚至出现db无法响应新的查询
解决方法
- 缓存空值
如一个不存在的userlD，这个id在缓存和数据库中都不存在，则可以缓存一个空值，下次再查缓存直接反空值
- 布隆过滤器
通过bloom filter算法来存储合法Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值
- 使用缓存集群，避免单机宕机造成的缓存雪崩
