写在前面
深入业务，才能有好的设计。在设计缓存的时候，要根据我们的业务特点，明白什么是不容易变的，什么是相对容易变，什么是真正触达用户的，哪些数据是关键。这样才能发现真正应该cache的点。
什么时候用缓存
缓存访问频率高、变化频率低的数据
使用原则：在一致性要求不高（高一致性例如交易的账户）的情景下，数据层读服务必须加缓存
数据服务：直接跟DB交互的读服务需要根据数据一致性要求（强弱分辨）加缓存
业务服务：调用大量的外部读服务拼装结果的需要加缓存
缓存数据要尽可能的贴近用户端，尽量高的从各类缓存中命中数据，而不是访问数据库
何时不用缓存
对数据要求苛刻，变化频率高、访问频率低的数据不能缓存
缓存使用实现
cache implement
- 本地缓存：可用hashmap（注意并发）、guava-cache（推荐）等。对于一致性要求不高且缓存命中率较高的数据服务，本地缓存可以减少服务端调用次数；
- 集中缓存：又称分布式缓存，实现由redis（推荐）、memcache等。建议作为缓存使用，而不是存储。在数据变化频率很高的情况下，可作为DB的写入缓存
缓存的使用顺序
内存缓存>分布式缓存>数据库
缓存的设计原则
CacheDesignPrinciple
- 静态化：数据尽量以目标展现的格式存储，而不是存储中间数据。减少数据格式化的时间消耗，用空间换时间。
- 专用化：数据静态化后，可使用的范围有限，应尽量贴近用户的结构，降低使用后的格式化成本。
- 隔离化：封装缓存数据的访问，把缓存的控制权掌握在自己手中。
缓存同步模式
- 增量同步：按照时间戳或者数据变化更新缓存。
- 全量同步：重新拉取所有的缓存数据。不建议采用此种模式，性能差，同步的数据量大。
缓存同步时机
- 每次查询时同步：在做查询时，检验数据的版本，然后进行缓存同步。
- 增删改时失效：在做数据的增删改时，同步修改缓存。
- 定时同步：在缓存的驻留端定时更新缓存。此种模式适用于对数据的实时性要求不高的场景。
缓存时效性
- 有时效性：缓存数据存在时效性，不管数据的版本有没有变化，过期失效。
- 无时效性：只要数据的时间戳保持不变，缓存数据永久有效。
缓存使用原则
- 越少的缓存使用，越有价值。
- 离最终的计算结果越近，越有价值。
- 对于需要消耗I/O资源的缓存，要尽可能的减少调用的次数。
反复缓存所导致性能恶化的原因是无节制地使用缓存。缓存使用的指导原则是：工程师们在使用缓存时必须全局考虑，精细规划，确保数据完全缓存的情况下，系统仍然不会频繁full GC。为了确保这一点，对于存在多种类型缓存以及系统流量变化很大的系统，设计者必须严格控制缓存大小，甚至废除缓存（这是典型为了提高流量高峰时可用性，而降低平均响应时间的一个例子）。反复缓存反模式往往发生在流量高峰时候，通过线性增加机器和提高机器内存可以大大减少系统崩溃的概率。
缓存使用注意事项
- 缓存对象大小限制
- 高频和低频分离
- 缓存过期时间设置
- 防止缓存击穿雪崩ask
- 服务过载的cache应对策略
- 缓存自动加载技法 guava-cache的loading模式可以参考
- 禁用堆外内存
- null值得缓存
- 分布式换成考虑序列化和反序列化成本 & key的分布情况，不要分散到过多的节点
缓存的评审
- 在系统设计阶段对缓存使用进行评审
- 在code-review阶段进行缓存review
