缓存数据查询-简述

背景

缓存数据查询流程：simple_flow_A：Get+Cahce

1. 查询缓存是否有数据；若有直接返回；
2. 如无则查询数据库是否有数据；如无直接返回；
3. 若有则将查库数据更新至缓存；
4. 返回最新数据；

问题来源

• 高并发；
  • 要保证缓存机制能在高并发的情况下照常执行；
• 异常请求对缓存机制的影响；
  • 异常：业务范围之外的请求参数；
  • 需要过滤或处理异常请求，防止跳过缓存，使缓存机制失效；

问题场景

执行上述流程时：simple_flow_A

• 缓存无数据（缓存数据过期or缓存数据初始化）
• 数据库无数据

核心问题点

• 缓存穿透

  • case_A：利用缓存中实际不存在的key恶意大量请求，将请求压力直接附加到数据库层；
  • 核心：问题的根本是不存在的key是不会存在放缓存中的，所以缓存机制针在此场景下并不生效，需要规避此场景；
  • solution_A：思路：1：解决value为空时不存放缓存的机制；2：在工具层匹配是否为指定返回结果，不影响调用方or调用方法；
  • solution_A：细节：1：将值不存在的key也通过指定value存在放缓存中；2：获取时判断值是否数据指定value，如果是，判定为空；
  • solution_A：影响：1：一定要保证存指定value（逻辑空值）的key在有实际真正value时能顺利更新缓存；
    2：并且此类过期时间应小于正常缓存；否则大量恶意请求每个Key都不同，则会产生大量的无效性缓存存储量；
  • solution_B：思路：API算法过滤参数，快速失败返回；TODO；

• 缓存击穿（又称：缓存并发）

  • case_A：高并发场景下，执行simple_flow_A时：当缓存失效或者不存在时（常规情况下存在的需要请求数据库的环节），会有大量请求并行请求数据库；
  • case_B：假如在缓存初始化的阶段（第一次访问数据时），如果是高并发，如果按照simple_flow_A；这其中涉及操作原子性的问题，
    因为涉及了两个环节：查库&set缓存；两个并行的现成如果出现了A+C：Update+BBA的情况（并行的时序性无法保证并且不同线程直接出现了数据变更，
    导致set缓存的时候出现了两个数据源，并且线程间执行先后顺序无法保证），即会数据覆盖，最终数据不一致（脏数据）的情况；
  • 核心：需要互斥性&原子性
  • solution_A：思路：code的方式将查库&set缓存包装成为原子操作；
  • solution_A：细节：引入分布式事务锁来实现互斥功能，实现原子操作；锁的内外针对缓存的值进行DoubleCheck，实现原子操作的前提下也保证不会有冗余操作影响缓存机制；
    特殊的：引入锁是为了保证同一时间节点上并发操作的问题，不应该影响不在同一时间节点上的请求处理，上述细节中有个漏洞，就是如果进入锁查库的结果是
    空的时候我们需要采用解决“缓存穿透”的基本方案设置指定value进缓存，否则后续请求也会在缓存和数据库之间反复查询，并且中间还有锁的介入；
  • solution_A：影响：高并发情况下当锁定锁之后后续现成会出现短暂的等待；

• 缓存雪崩

  • case：与缓存穿透和缓存击穿不同的原因是单点数据缓存问题导致的不同，缓存雪崩是因为站点内大量不同类型数据的缓存同时到期，导致数据库总符合陡增产生的影响；
  • 核心：努力让过期时间段均匀分布；
  • solution_A：加锁排队；即上述“缓存击穿”的solution_A，即使出现大量不同数据类型导致的广义的击穿，单每种类型数据的数据库压力是可控唯一的；
  • solution_B：随机过期时间；如果不影响功能，可以将过期时间在指定范围内做随机设置；
  • solution_C：永不过期处理（物理or逻辑上永不过期处理）；
  • solution_D：特殊情况可以考虑长短期缓存并行使用；

• 热点数据

  • case：如果存在类似需要缓存的数据类型，同类型下不同数据访问的频率是不同的，并且访问规律存在一定的变化性；
  • solution_A：设置缓存定长列表，并且通过热点规则进行排序，定期清理尾部元素实现自更新；

结论

• 对于缓存穿透，缓存并发，缓存雪崩三种缓存常见问题场景，我们需要做到的基本工作：
  • 存放空值&加锁排队，满足缓存穿透和缓存并发的需求，并且这两种方案组合一定程度上能处理雪崩的情况；
• 雪崩问题如果优先级较高，还可以并行使用永不过期（物理or逻辑）策略；