redis 基础概念深入学习+图例阐述

1 redis 基础概念学习

1.1 redis数据一致性问题

概念：由于使用redis作为缓存， 一定会引入数据一致性问题。如何保证redis和数据库的一致性问题，是重中之重。

1.1.1 主动更新策略：

• Cache Aside Pattern（**胜出**）
  由缓存调用者在更新数据库时主动更新缓存
• Read/Write Through Pattern
  缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。
• Write Behind Caching Pattern
  调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证最终一致。

1.1.2 主动更新策略会引入以下问题，操作缓存和数据库时有三个问题需要考虑

• 删除缓存还是更新缓存

  • 删除缓存
    • 更新数据库时，将原有缓存删除。下次查询时缓存未命中，会从数据库重新获取，再更新缓存（更新缓存在查询数据阶段）——胜出
    • 因为在上百次写操作时，若没有读操作，每次更新数据库同时更新缓存会造成上百次无效的更新缓存操作；而删除缓存只会删除一次，若存在读操作时，再去更新缓存
  • 更新缓存
    • 更新数据库时，同步更新缓存。（更新缓存在更新数据阶段）

• 如何保证缓存与数据库的操作的同时成功或失败

  • 若是单机模式或单线程模式，在二者操作放入同一事务即可
  • 若是分布式模式，需要利用TCC等分布式事务方案

• 先操作缓存还是先操作数据库
  - 在上述条件下： 缓存未同步情况，只能是缓存未命中，在数据库更新前查询，写入缓存；最终都会更新数据库，再此只讨论数据库更新了，缓存却未更新的情况

  以下图例：左图是正常流程，右图是发生线程安全问题流程

  • 先删除缓存，在操作数据库
    
    在此情况下，只能是在删除存后，另一线程发生读操作，且查询数据库写入缓存，由于数据库操作耗时较长，查询缓存并写入缓存耗时短，该情况**发生概率较大**

  • 先操作数据库，再删除缓存
    在此情况，只有当线程1发生读操作时，刚好该key TTL到期，然后线程2更新数据库和更新缓存飞速执行，最后线程1写入缓存，方可导致。这情况发生概率较小，需同时满足以下三种情况：

    （1）刚好遇到key TTL，否则，缓存命中直接return

    （2）更新数据库+删除缓存的耗时 < 写入缓存耗时 （一般数据库操作耗时较长，远大于写缓存）

    （3）写缓存要在删除缓存之后，否则，后续线程2会再次将缓存删除，会重新触发更新缓存操作

  总结： 优先考虑先更新数据库再删除缓存的逻辑。

1.2 缓存穿透问题

概念：redis和数据库中都不存在，导致请求都会直接打到数据库

解决方案：

• 缓存null值——当数据库不存在时，向redis缓存null值
  • 优点：实现简单、方便维护
  • 缺点：
    • 当用户随意输入大量无效请求，数据库未存在，都会缓存null值（额外内存消耗）
    • 短期内数据不一致问题（可设置较短的TTL）
• 布隆过滤器
  • TODO

1.3 缓存雪崩问题

概念：当redis中大量key同时出现TTL或服务器宕机现象，导致该部分请求直接打到数据库，造成资源拥挤。

解决方案：

• 为key设置随机的TTL（因为是key同时失效导致，为key设置一段区间的随机值）
• 搭建集群模式（redis哨兵监控，主从选举）
• 给业务添加降级限流策略（如服务器宕机，将该部分请求直接拒绝，防止大量请求打到数据库）
• 给业务添加多级缓存（浏览器缓存（一般静态资源）-> nginx缓存 -> redis缓存 -> jvm缓存 （应用层缓存？例如使用HashMap？）-> 数据库）

1.4 缓存击穿问题

概念：也称为热点key问题，当访问redis高并发key时并且热点key重建业务耗时较长，该部分请求打到数据，导致资源拥挤。

有时重建缓存需要在查询数据库数据基础上，增加数据处理逻辑，若耗时较长，每当一个读请求过来->发现缓存未命中->尝试重建缓存。此时所有的请求都直接打到数据库，都会尝试重建缓存。

解决方案：

• 互斥锁

  以下用时序图来阐述
  
  在上述图中，线程1查询数据，缓存未命中后尝试获取锁，获取锁成功，进入查找数据库及重建缓存阶段，最终释放锁。

  而其他线程来了读操作，比如线程2查询数据，尝试获取锁，获取锁失败，就会让该线程sleep(time)，休眠后再重试查询数据，直到线程1释放锁（代表缓存重建成功），此时线程2查询数据时，缓存命中，直接return。

• 逻辑过期

  key	value
  cache:order:1	{id:1,expire:152142133}

  此时的expire是逻辑过期时间：比如是服务器启动时间 + 30min 的时间戳

  
  在此情况下，缓存是不会被删除，也没有设置TTL，所以缓存一定命中。但是要检测逻辑是否过期，
  left = currentTimeStamp - expire > 30 * 60 * 1000

  线程1查询数据，若是逻辑缓存过期，则获取锁并开启新的线程（线程2）。此时线程1 直接return old data。

  线程2查找数据库，重建缓存并更新逻辑过期时间，写入缓存，最后释放锁。

  线程3倘若在线程2释放锁之前，进入读操作，查找数据缓存命中，判断逻辑是否过期，若过期，则尝试获取锁，获取成功的话，则代表线程2已经更新缓存，此时获取的就是新缓存。

  线程4进入读操作，判断缓存是否过期，未过期则直接return。