赞
踩
原创 不码不疯魔 不码不疯魔 2023-08-05 07:44 发表于四川
收录于合集
#redis2个
#数据一致性4个
#分布式缓存1个
#分布式缓存与DB数据一致性1个
20
23
不疯魔不成活,大家好呀,我是科哥,江湖ID 不码不疯魔
真实场景:
面试官:你好,请问你做过的项目中,服务的最高QPS是多少?
候选人:我们的服务高峰访问量非常大,在双十一活动的时候 QPS大概10w左右
面试官:这么大的访问量,服务面临的压力应该非常高,你们是怎么设计的呢?
候选人:我们的服务设计是采用了二级缓存,把一些热点的数据放到本地缓存,比如活动的数据,把一些非热点的数据放到 Redis 缓存,比如活动-礼品数据,接口优先查询一级缓存,如果一级缓存没数据,接着会查询二级缓存,二级缓存不存在,才访问数据库。这样设计可以减少数据库的访问压力,加快查询效率。
面试官:从你的设计看,你的数据存储到三个地方,如果涉及数据更新,你是怎么保证他们三者中间的一致性的呢?
面试官:这样,说说分布式缓存与DB的一致性问题是如何解决的?
看
重
点
重点掌握:4套方案+1套兜底的实现步骤、优点、缺点?
1. 方案一:基于binlog+Canal+Redis方案(适合强一致性)
2. 方案二:基于binlog+Canal+Redis+ES+MQ方案(比较解耦,复杂)
3. 方案三:延迟双删方案(适合非高并发)
4. 方案四:基于定时任务方案(适合最终一致性)
5. 兜底方案:自动或手工补偿方案(兜底)
注意:此篇文章,只讲实现步骤+优缺点,具体的商用级代码很快更新,记得关注,标记星号哟!!!
01
方案一:基于binlog+Canal+Redis方案(适合强一致性)
步骤:
1.更新 MySQL 数据;
2.通过canal中间件监听MySQL中的binlog;
3.启动一个数据处理应用,消费同步canal监听的数据并进行数据加工;
4.将加工后的数据更新至Redis;
5.应用查询Redis数据返回;
优点:
1.实现简单:该方案所需的组件较少,实现较为简单。
2.高效同步:通过Canal机制,可以实现数据库与缓存之间的实时同步,保证了数据的一致性。
3.主从复制:使用MySQL的主从复制机制,可以保证从服务器MySQL上的数据与主服务器保持同步,进一步保证了数据的一致性。
缺点:
1.依赖MySQL:该方案依赖于MySQL数据库,对于非MySQL数据库的环境可能不适用。
2.技术限制:该方案需要配置主从复制和Canal机制,对于一些特殊的环境或者限制可能不适用。
3.数据丢失:如果在数据写入Redis缓存之前发生系统故障或宕机,可能会造成数据丢失。
4.维护难度:需要维护Redis缓存和MySQL数据库的主从复制关系,如果系统规模较大或数据量较大,可能需要更多的维护和管理成本。
02
改方案二:基于binlog+Canal+Redis+ES+MQ方案(比较解耦,复杂)
步骤:
1.更新MySQL数据;
2.通过canal中间件监听MySQL中的binlog,同时将数据同步到MQ;3.启动一个数据处理应用,消费MQ数据并进行加工;
4.将加工后的数据更新至Redis,加入ES;
5.应用查询Redis数据返回;
优点:
1.实现高效同步、主从复制、支持全文搜索和数据分析等
2.消息队列实现异步处理和事件通知,可以进一步提高系统的可靠性和性能。
缺点:
1. 维护Redis、ES和消息队列等组件,技术限制较大,可能需要在一些特殊环境下 进行额外的配置和优化等。
03
方案三:延迟双删方案(适合非高并发)
步骤:
1. 先进行缓存清除;
2. 再执行update sql;
3. 最后(延迟 N 秒)再执行缓存清除;
上述中(延迟 N 秒)的时间要大于一次写操作的时间,一般为 3-5 秒。
原因:如果延迟时间小于写入 Redis 的时间,会导致请求 1 清除了缓存,但是请求 2 缓存还未写入的尴尬。
注意:一般写入的时间会远小于 5 秒
优点:
1.方案相对比较简单,对于非高并发业务比较适合。
缺点:
1.有等待环节,如果系统要求低延时,这种场景就不合适
2.不适合秒杀这种频繁修改数据和要求数据强一致的场景
3.延时时间是一个预估值,不能确保 MySQL 和 Redis 数据在这个时间段内都实时同步或持久化成功了
04
方案四:基于定时任务方案(适合最终一致性)
步骤:
1. 更新 db 数据,同时写入数据到 redis
2. 启动一个定时任务定时将 db 数据同步到 redis
3. 前端发起接口查询请求,先从 redis 查询数据
4. 没有数据redis,加一个分布式锁,再从 redis 数据查询
5. 查询 redis 数据返回
优点:
1.方案相对比较简单,对于高并发业务比较适合。相对是一个比较高可用的方案, 通过定时任务定时更新db数据到 redis,保持数据的一致性。
缺点:
1.并不能保证数据的实时性,如果对数据的实时性要求比较高,则需要考虑其他解决方案。
05
兜底:自动或手工补偿方案(兜底)
自动补偿方案:
1.数据写入数据库:当数据发生更新或删除时,首先将数据写入数据库,以保证数据的一致性。
2.数据写入缓存:在数据写入数据库后,立即将数据写入缓存,以保证数据的一致性。
3.数据同步:使用定时任务或消息队列等机制,定时将数据库中的数据同步到缓存中,以避免数据不一致的情况。
4.数据更新:当数据库中的数据发生更新或删除时,通过触发事件或定时任务来更新缓存中的数据,以保证数据的一致性。
手工补偿方案:
1.数据写入数据库:当数据发生更新或删除时,首先将数据写入数据库,以保证数据的一致性。
2.数据写入缓存:在数据写入数据库后,立即将数据写入缓存,以保证数据的一致性。
3.数据同步:开发人员手动编写代码,定时将数据库中的数据同步到缓存中,以避免数据不一致的情况。
4.数据更新:当数据库中的数据发生更新或删除时,开发人员手动编写代码来更新缓存中的数据,以保证数据的一致性。
优点:
1.对于适合秒杀类业务,另外通过定时任务自动补偿和手工补偿,这种方案高可用方面做的比较好。甚至能做到自动修复不一致性的场景。
缺点:
1. 需要开发额外的定时任务
收获
文档资料
笔记文档,怎么获取?
点击下方公众号进入关注,后台回复【4+1】即可获取所有资料,具体的商用级代码很快更新,记得关注,标记星号哟!!!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。