Redis 缓存设计原则
[TOC]
基本原则
- 只应将热数据放到缓存中
- 所有缓存信息都应设置过期时间
- 缓存过期时间应当分散以避免集中过期
- 缓存key应具备可读性
- 应避免不同业务出现同名缓存key
- 可对key进行适当的缩写以节省内存空间
- 选择合适的数据结构
- 确保写入缓存中的数据是完整且正确的
- 避免使用耗时较长的操作命令，如：keys *
- Redis默认配置中操作耗时超过10ms即视为慢查询
- 一个key对应的数据不应过大
- 对于string类型，一个key对应的value大小应控制在10K以内，1K左右更优
- hash类型，不应超过5000行
- 避免缓存穿透
- 数据库中未查询到的数据，可在Redis中设置特殊标识，以避免因缓存中无数据而导致每次请求均达到数据库
- 缓存层不应抛出异常
- 缓存应有降级处理方案，缓存出了问题要能回源到数据库进行处理
- 可以进行适当的缓存预热
- 对于上线后可能会有大量读请求的应用，在上线之前可预先将数据写入缓存中
- 读的顺序是先缓存，后数据库；写的顺序是先数据库，后缓存
- 数据一致性问题
- 数据源发生变更时可能导致缓存中数据与数据源中数据不一致，应根据实际业务需求来选择适当的缓存更新策略：
- 主动更新：在数据源发生变更时同步更新缓存数据或将缓存数据过期。一致性高，维护成本较高。
- 被动删除：根据缓存设置的过期时间有Redis负责数据的过期删除。一致性较低，维护成本较低。
- 数据源发生变更时可能导致缓存中数据与数据源中数据不一致，应根据实际业务需求来选择适当的缓存更新策略：
缓存过期算法
- LRU
- 淘汰最后使用时间距当前时间较长的数据
- LFU
- 淘汰某段时间内的使用频次较低的数据
- FIFO
- 淘汰先写入的数据
