Redis的缓存更新策略及最佳实践方案
作者：程序员阿红
这篇文章主要介绍了Redis的缓存更新策略及最佳实践方案,当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把它成为淘汰更合适,需要的朋友可以参考下
缓存更新
缓存的更新是redis为了节约内存而设计出来的东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把它成为淘汰更合适。
1.redis的缓存更新的三种策略
- 内存淘汰
- redis自动进行，当redis内存达到咱们设定的max-memery的时候会自动触发淘汰机制，淘汰调一些不重要的数据（自己可以设置策略方式）
- 超时剔除
- 当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，方便咱们继续使用缓存。
- 主动更新
- 我们可以手动条用方法把缓存删掉，通常用于解决缓存和数据库不一致问题。
主动更新有分三种方式：
- 由缓存的调用者，在更新数据库的同时更新缓存。
- 缓存和数据库整合为一个服务，由服务来维护一致性。调用者调用该服务（对外提供一个透明的服务），无需关系缓存一致性问题。
- 调用者只操作缓存，有其他线程异步的将缓存持久化到数据库，保证最终一致。（类似于数据库的索引，一个索引更新在没有提交事务时，修改了100次只有最后一次有效，但这会使效率降低。）
如果采用第一个方案，那么假设我们每次操作数据库后，都操作缓存，但是中间如果没有人查询，那么这个更新动作实际上只有最后一次生效，中间的更新动作意义并不大，我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来
- 删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都更新缓存，无效写操作较多
- 删除缓存：更新数据库时让缓存失效，查询时再更新缓存
- 如何保证缓存与数据库的操作的同时成功或失败？
- 单体系统，将缓存与数据库操作放在一个事务
- 分布式系统，利用TCC等分布式事务方案
- 先操作缓存还是先操作数据库？
- 先删除缓存，再操作数据库 （第一种方案）
- 先操作数据库，再删除缓存
应该具体操作缓存还是操作数据库，我们应当是先操作数据库，再删除缓存，原因在于，如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。
redis的读写是微秒级别的，但是数据库的更新时远远比redis的读写慢的。
三者之间比较
2. 缓存更新策略的最佳实践方案：
- 低一致性需求：使用Redis自带的内存淘汰机制
- 高一致性需求：主动更新，并以超时剔除作为兜底方案
- 读操作：
- 缓存命中则直接返回
- 缓存未命中则查询数据库，并写入缓存，设定超时时间
- 写操作：
- 先写数据库，然后再删除缓存
- 要确保数据库与缓存操作的原子性
到此这篇关于Redis的缓存更新策略及最佳实践方案的文章就介绍到这了,更多相关Redis缓存更新策略内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！