【Redis】缓存实战解决方案--Part1 缓存更新策略

【Redis】 缓存实战解决方案

一、缓存更新策略

缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。

内存淘汰：redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动触发淘汰机制，淘汰掉一些不重要的数据(可以自己设置策略方式)

超时剔除：当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，方便咱们继续使用缓存

主动更新：我们可以手动调用方法把缓存删掉，通常用于解决缓存和数据库不一致问题

1.1 数据库缓存不一致解决方案

由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在,其后果是:

用户使用缓存中的过时数据,就会产生类似多线程数据安全问题,从而影响业务等。

• 解决方案：

  • Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库后再去更新缓存，也称之为双写方案

  • Read/Write Through Pattern : 由系统本身完成，数据库与缓存的问题交由系统本身去处理

  • Write Behind Caching Pattern ：调用者只操作缓存，其他线程去异步处理数据库，实现最终一致

1.2 数据库和缓存不一致解决方案

综合考虑使用双写方案

操作缓存和数据库时有三个问题需要考虑：

如果采用双写方案，假设我们在操作数据库的时候，都操作缓存；这时期间如果没有人查询，这个缓存更新动作只有最后一次生效，那么这个更新操作意义并不大。

我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来

• 删除缓存还是更新缓存？

  • 更新缓存：每次更新数据库都更新缓存，无效写操作较多

  • 删除缓存：更新数据库时让缓存失效，查询时再更新缓存

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

  • 单体系统，将缓存与数据库操作放在一个事务

  • 分布式系统，利用TCC等分布式事务方案

对于是先操作缓存还是先操作数据库？

先操作数据库再操作缓存。

原因：如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。

先操作缓存还是先操作数据库？

• 先删除缓存，再操作数据库

• 先操作数据库，再删除缓存