redis缓存延时双删的原因分析

基于 spring aop 常规应用场景多是用于日志记录以及实现 redis 分布式锁,在 github 中也有项目是把它拿来当作缓存的异常捕捉.从而避免影响实际业务的开发:在某天,笔者有个业务开发是给某个服务模块增加 redis 缓存.增加缓存就会涉及 redis 删除.所以笔者就在思考是不是可以用环绕通知的方式来进行实现 代码实现 结构示意图: 自定义注解 RedisDelByDbUpdate @Repeatable 表示允许在同一个地方上使用相同的注解,没有该注解时贴相同注解会报错 @Ta

目录 一.延时队列的应用 二.延时队列的实现 三.总结 一.延时队列的应用 近期在开发部门的新项目,其中有个关键功能就是智能推送,即根据用户行为在特定的时间点向用户推送相应的提醒消息,比如以下业务场景: 在用户点击充值项后,半小时内未充值,向用户推送充值未完成提醒. 在用户最近一次阅读行为2小时后,向用户推送继续阅读提醒. 在用户新注册或退出应用N分钟后,向用户推送合适的推荐消息. … 上述场景的共同特征就是在某事件触发后延迟一定时间后再执行特定任务,若事件触发时间点可知,则上述逻辑也可等价于在

目录 什么是延时任务 延时任务的特点 实现思路: 代码实现 1.消息模型 2.RedisMq 消息队列实现类 3.消息生产者 4.消息消费者 5. 消息执接口 6. 任务类型的实现类:可以根据自己的情况去实现对应的队列需求 什么是延时任务 延时任务,顾名思义,就是延迟一段时间后才执行的任务.举个例子,假设我们有个发布资讯的功能,运营需要在每天早上7点准时发布资讯,但是早上7点大家都还没上班,这个时候就可以使用延时任务来实现资讯的延时发布了.只要在前一天下班前指定第二天要发送资讯的时间,到了第二天

缓存为啥是删除,而不是更新? 如果是更新,存在分布式事务问题,可能出现修改了缓存,数据库修改失败的情况.只是删除缓存的话,就算数据库修改失败,下次查询会直接取数据库的数据,也不会出现脏数据. 延时双删是什么? 就是在增删改某实体类的时候,要对该实体类的缓存进行清空,清空的位置在数据库操作方法的前后. 采用反证法 只先删  只后删 结论 从而得出 前删和后删都有问题.所以采用延时双删的策略 思考2:为啥是延时 依然是反证法.下图这情况是双删依然存在旧缓存的情况,延时是确保 修改数据库->清

目录 一.业务场景 1.此时存在的问题 2.解决方案 3.为何要延时500毫秒? 4.为何要两次删除缓存? 二.代码实践 1.引入Redis和SpringBoot AOP依赖 2.编写自定义aop注解和切面 3.application.yml 4.user_db.sql脚本 5.UserController 6.UserService 三.测试验证 四.代码工程及地址 一.业务场景 在多线程并发情况下,假设有两个数据库修改请求,为保证数据库与redis的数据一致性,修改请求的实现中需要修改数据库

1 什么是一致性? 一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的. 强一致性: 这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验性好,但实现起来往往对系统的性能影响大: 弱一致性: 这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态: 最终一致性: 最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一

目录 一.问题描述 二.解决方案 1.给缓存数据设置过期时间 2.缓存延时双删 3.删除缓存重试机制 4.读取biglog异步删除缓存 三.总结 一.问题描述 redis.mysql双写缓存不一致: 在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存.又或者是先删除缓存,再更新数据库,其实大家存在很大的争议.于是博主战战兢兢,写了这篇文章. 二.解决方案 1.给缓存数据设置过期时间 先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案.这种方案下,我们可以对存入缓

目录 一.一致性 1.强一致性 2.弱一致性 3.最终一致性 二.redis缓存和mysql数据库数据一致性解决 1.方案一:采用延时双删策略 2.方案二:一步更新缓存(基于订阅Binlog的同步机制) 首先,我们先来看看有哪几种一致性的情况呢? 一.一致性 1.强一致性 如果你的项目对缓存的要求是强一致性的,那么请不要使用缓存.这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大. 2.弱一致性 这种一致性级别约束了系统在写入成