抠图接口缓存：图片参数输入，结果返回；通过框架封装到本地缓存中

还可以通过用户 ID hash 处理到不同服务上，继续使用本地缓存

## 缓存方案
- 一致性哈希 + 本地缓存 + Redis
  - 适用广泛：很多业务都可以使用
  - 步骤
    - 1. 客户端使用一致性哈希负载均衡，确保同一个业务的请求一定落到同一节点上
    - 2. 服务端先查询本地缓存，再查询Redis缓存
    - 3. 缓存都没有，就回查数据库
    - 4. 回写缓存的时候，先写本地缓存
  - 优点：性能好、本地缓存命中率高、本地缓存使用内存更少
- Redis降级成本地缓存
  - 目的：保住数据库
  - 步骤
    - 1. 在Redis 正常的时候，先查询 Redis，再查询数据库
    - 2. 如果发现 Redis 崩溃，就启用本地缓存
    - 3. 启用本地缓存之后，先查本地缓存，再查询数据库
    - 4. 与此同时，保持监控 Redis 的状态
    - 5. 如果 Redis 恢复了，就将流量逐步发送转移过去
  - 缺点：降级到本地缓存之后，数据一致性问题比使用 Redis 更严重；可以结合一致性哈希负载均衡策略缓解一致性问题
- 请求级别缓存
  - 步骤
    - 1. 缓存的有效期和请求保持一致
    - 2. 在请求返回响应的时候，直接清空缓存（用 Web 框架/ RPC 框架的 AOP 方案）
  - 优点：数据一致性强
  - 缺点：适用场景少；需要中间件支持
- 会话级别缓存
  - 步骤
    - 1. 缓存有效期和会话有效期保持一致
    - 2. 在会话结束的时候，直接清空缓存
  - 优点：数据一致性较强；适用范围比较广泛
- 客户端缓存
  - 步骤
    - 1. 客户端调用服务端接口，获得的数据直接缓存在客户端这边
    - 2. 客户端优先查找自己缓存的数据
  - 优点：性能好；数据局部性更好，不会被服务端的缓存淘汰策略影响到；少了一次网络调用
  - 缺点：数据一致性问题比较严重
- 业务相关缓存预加载
  - 步骤
    - 1. 用户调用了 A 接口之后大概率要调用 B 接口
    - 2. 服务 A 把接口 B 中可能需要的数据提前缓存
    - 3. 在 A 接口返回之后异步地提前加载 B 接口所需要的数据
  - 优点：性能好
  - 缺点：如果 B 接口最终没调用，就浪费了资源；通过设置过期时间来减少资源浪费
- 缓存预热和预加载
  - 步骤
    - 启动时就加载
      - 全量加载：只加载热点数据
    - 灰度流量加载
      - 先小流量预热再加载；逐步加大流量
      - 可以通过负载均衡来控制流量，比如基于权重的负载均衡
- 总结
  - 在前端部分，你用了什么和缓存有关的技术来提高性能？
  - 在 Session 层使用会话级别缓存
  - 发起微服务调用的时候，应用客户端缓存
  - 具体微服务：使用一致性哈希负载均衡策略 + 本地缓存 + Redis 缓存
  - 调整第三方中间件的缓存设置：例如 MySQL、InnoDB 的 buffer pool