Redis(九) 缓存设计

1 需要加缓存吗？

在构建和优化业务服务时，首先想到的应该是优化数据库，比如数据库模型设计、SQL结构化查询语句优化，慢查询往往是系统性能杀手。其次是使用缓存。

权衡缓存的收益与成本：
缓存所带来的性能提升效果更直接、高效：高性能、高并发，读写速度快，降低后端负载。
任何系统使用缓存，都会遇到两大问题：数据不一致问题、系统复杂度增加。

2 缓存的设计与使用？

衡量缓存设计好坏的指标是缓存命中率，缓存的命中率=缓存命中次数/请求次数，命中率越高，缓存的使用率越高。
缓存的适用场景总的来说是缓存高频读低频写的数据。相反变化频率高、访问频率低的数据不适合缓存。

设计和使用缓存首先要了解服务、DB、Cache的性能情况。

2.1 选择分布式缓存的设计模式？

Cache Aside Pattern（数据不一致概率低，读操作多的场景）/
Read Write Through Pattern（应用端代码维护简单）/
Write Behind Pattern（写性能最高，写操作多的场景，但是数据安全性较差）
根据 读写场景、性能要求、数据不一致的容忍程度、代码维护 选择合适的模式。

2.2 缓存粒度控制？

缓存全部数据还是部分数据？
需要考虑缓存命中率、通用性、空间占用、代码复杂度。
缓存命中率：缓存全部数据的命中率低于缓存热点数据。
通用性：缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。
空间占用：缓存全部数据要比部分数据占用更多的空间。
代码复杂度：缓存全部数据的代码会更简洁。

2.3 如何保证缓存的数据是热点数据？

设置缓存淘汰策略用来保证缓存中存储的是热点数据。
为缓存数据设置过期时间。
低一致性业务建议配置最大内存和缓存淘汰策略（LRU LFU FIFO）的方式使用。
高一致性业务可以结合过期删除和主动更新策略。（双更 先更再删 异步重试）

2.4 缓存引入的问题？

缓存穿透 缓存击穿 缓存雪崩 数据不一致 主从不一致

总结：

深入业务，才能有好的设计。设计缓存时要根据业务特点，明白什么是不容易变的，什么是相对容易变，客户对于数据不一致性的容忍程度。这样才能发现真正应该缓存的点。

参考：
缓存设计：https://javakeeper.starfish.ink/data-management/Redis/Cache-Design.html
缓存的设计与使用：https://zhuanlan.zhihu.com/p/94847283