Redis 典型应⽤ - 缓存 cache
什么是缓存
缓存 (cache) 是计算机中的⼀个经典的概念. 在很多场景中都会涉及到.
核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅, ⽅便随时读取.
对于计算机硬件来说, 往往访问速度越快的设备, 成本越⾼, 存储空间越⼩.
缓存是更快, 但是空间上往往是不⾜的. 因此⼤部分的时候, 缓存只放⼀些 热点数据 (访问频繁的数据),就⾮常有⽤了.
使⽤ Redis 作为缓存
在⼀个⽹站中, 我们经常会使⽤关系型数据库 (⽐如 MySQL) 来存储数据.
关系型数据库虽然功能强⼤, 但是有⼀个很⼤的缺陷, 就是性能不⾼. (换⽽⾔之, 进⾏⼀次查询操作消耗的系统资源较多).
为什么说关系型数据库性能不⾼?
- 数据库把数据存储在硬盘上, 硬盘的 IO 速度并不快. 尤其是随机访问.
- 如果查询不能命中索引, 就需要进⾏表的遍历, 这就会⼤⼤增加硬盘 IO 次数.
- 关系型数据库对于 SQL 的执⾏会做⼀系列的解析, 校验, 优化⼯作.
- 如果是⼀些复杂查询, ⽐如联合查询, 需要进⾏笛卡尔积操作, 效率更是降低很多.
因此, 如果访问数据库的并发量⽐较⾼, 对于数据库的压⼒是很⼤的, 很容易就会使数据库服务器宕机.
为什么并发量⾼了就会宕机?
服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的. 所谓的硬件资源包括不限于 CPU,内存, 硬盘, ⽹络带宽...
⼀个服务器的硬件资源本⾝是有限的. ⼀个请求消耗⼀份资源, 请求多了, ⾃然把资源就耗尽了. 后续的请求没有资源可⽤, ⾃然就⽆法正确处理. 更严重的还会导致服务器程序的代码出现崩溃.
如何让数据库能够承担更⼤的并发量呢? 核⼼思路主要是两个:
- 开源: 引⼊更多的机器, 部署更多的数据库实例, 构成数据库集群. (主从复制, 分库分表等...)
- 节流: 引⼊缓存, 使⽤其他的⽅式保存经常访问的热点数据, 从⽽降低直接访问数据库的请求数量.
实际开发中, 这两种⽅案往往是会搭配使⽤的
Redis 就是⼀个⽤来作为数据库缓存的常⻅⽅案.
Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系统资源⽐MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤.
- Redis 数据在内存中, 访问内存⽐硬盘快很多.
- Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则.
就像⼀个 "护盾" ⼀样, 把 MySQL 给罩住了.
- 客⼾端访问业务服务器, 发起查询请求
- 业务服务器先查询 Redis, 看想要的数据是否在 Redis 中存在.
- 如果已经在 Redis 中存在了, 就直接返回. 此时不必访问 MySQL 了.
- 如果在 Redis 中不存在, 再查询 MySQL.
按照上述讨论的 "⼆⼋定律" , 只需要在 Redis 中放 20% 的热点数据, 就可以使 80% 的请求不再真正查询数据库了.
缓存的更新策略
接下来还有⼀个重要的问题, 到底哪些数据才是 "热点数据" 呢?
1) 定期⽣成
每隔⼀定的周期(⽐如⼀天/⼀周/⼀个⽉), 对于访问的数据频次进⾏统计. 挑选出访问频次最⾼的前 N%的数据.
这种做法实时性较低. 对于⼀些突然情况应对的并不好.
⽐如春节期间, "春晚" 这样的词就会成为⾮常⾼频的词. ⽽平时则很少会有⼈搜索 "春晚".
2) 实时⽣成
先给缓存设定容量上限(可以通过 Redis 配置⽂件的 maxmemory 参数设定).
接下来把⽤⼾每次查询:
- 如果在 Redis 查到了, 就直接返回.
- 如果 Redis 中不存在, 就从数据库查, 把查到的结果同时也写⼊ Redis.
如果缓存已经满了(达到上限), 就触发缓存淘汰策略, 把⼀些 "相对不那么热⻔" 的数据淘汰掉.
按照上述过程, 持续⼀段时间之后 Redis 内部的数据⾃然就是 "热⻔数据" 了.
通⽤的淘汰策略主要有以下⼏种:
这⾥的淘汰策略, 我们可以⾃⼰实现. 当然 Redis 也提供了内置的淘汰策略, 也可以供我们直接使⽤.
缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿
关于缓存预热 (Cache preheating)
什么是缓存预热
使⽤ Redis 作为 MySQL 的缓存的时候, 当 Redis 刚刚启动, 或者 Redis ⼤批 key 失效之后, 此时由于Redis ⾃⾝相当于是空着的, 没啥缓存数据, 那么 MySQL 就可能直接被访问到, 从⽽造成较⼤的压⼒.
因此就需要提前把热点数据准备好, 直接写⼊到 Redis 中. 使 Redis 可以尽快为 MySQL 撑起保护伞.
热点数据可以基于之前介绍的统计的⽅式⽣成即可. 这份热点数据不⼀定⾮得那么 "准确", 只要能帮助MySQL 抵挡⼤部分请求即可. 随着程序运⾏的推移, 缓存的热点数据会逐渐⾃动调整, 来更适应当前情况.
关于缓存穿透 (Cache penetration)
什么是缓存穿透?
访问的 key 在 Redis 和 数据库中都不存在. 此时这样的 key 不会被放到缓存上, 后续如果仍然在访问该key, 依然会访问到数据库.
这就会导致数据库承担的请求太多, 压⼒很⼤.
这种情况称为 缓存穿透.
为何产⽣?
原因可能有⼏种:
- 业务设计不合理. ⽐如缺少必要的参数校验环节, 导致⾮法的 key 也被进⾏查询了.
- 开发/运维误操作. 不⼩⼼把部分数据从数据库上误删了.
- ⿊客恶意攻击.
如何解决?
- 针对要查询的参数进⾏严格的合法性校验. ⽐如要查询的 key 是⽤⼾的⼿机号, 那么就需要校验当前key 是否满⾜⼀个合法的⼿机号的格式
- 针对数据库上也不存在的 key , 也存储到 Redis 中, ⽐如 value 就随便设成⼀个 "". 避免后续频繁访问数据库.
- 使⽤布隆过滤器先判定 key 是否存在, 再真正查询.
关于缓存雪崩 (Cache avalanche)
什么是缓存雪崩
短时间内⼤量的 key 在缓存上失效, 导致数据库压⼒骤增, 甚⾄直接宕机.
为何产⽣?
⼤规模 key 失效, 可能性主要有两种:
- Redis 挂了.
- Redis 上的⼤量的 key 同时过期.
如何解决?
- 部署⾼可⽤的 Redis 集群, 并且完善监控报警体系.
- 不给 key 设置过期时间 或者 设置过期时间的时候添加随机时间因⼦
关于缓存击穿 (Cache breakdown)
什么是缓存击穿?
相当于缓存雪崩的特殊情况. 针对热点 key , 突然过期了, 导致⼤量的请求直接访问到数据库上, 甚⾄引起数据库宕机.
如何解决?
- 基于统计的⽅式发现热点 key, 并设置永不过期.
- 进⾏必要的服务降级. 例如访问数据库的时候使⽤分布式锁, 限制同时请求数据库的并发数.