对网站备案的认识,免费素材网站下载,工程施工合同免费版,做网站小程序的客户是怎么找的最近建了一个技术交流群#xff0c;欢迎志同道合的同学加入#xff0c;群里主要讨论#xff1a;分享业务解决方案、深度分析面试题并解答工作中遇到的问题#xff0c;同时也能为我提供写作的素材。 欢迎加Q#xff1a;312519302#xff0c;进群讨论 前言 在工作中#… 最近建了一个技术交流群欢迎志同道合的同学加入群里主要讨论分享业务解决方案、深度分析面试题并解答工作中遇到的问题同时也能为我提供写作的素材。 欢迎加Q312519302进群讨论 前言 在工作中大多数的系统都在使用缓存那你有没有想过为什么要使用缓存使用缓存后数据与缓存的一致性如何保证 带着上面的问题我们一起探索。 我们刚开始做一个项目的时候刚起步流量很小直接读写数据库即可性能不错系统稳定架构如下图 随时时间推移系统运行一段时间老板说要推广我们的系统给用户赋能接着搞一波营销流量激增结果系统报警了系统都快挂了赶紧排查发现性能瓶颈在数据库。 这好办给服务器加上 Redis让其作为数据库的缓存。 这样在客户端请求数据时如果能在缓存中命中数据那就查询缓存不用在去查询数据库从而减轻数据库的压力提高服务器的性能。 那我们的架构变为 看起来非常美好但是有个问提挡在我们面前如果数据库的数据有修改的时候我们是先更新数据库还是先更新缓存呢 由于引入了缓存那么在数据更新时不仅要更新数据库而且要更新缓存这两个更新操作存在前后的问题 先更新数据库再更新缓存先更新缓存再更新数据库 想了想为了保证数据是最新的数据那我们选择 先更新数据库再更新缓存 一顿操作猛如虎系统优化完成后上线数据库压力也下来吞吐量得到明显的提高心里那个激动啊我TM真是牛逼等着老板的嘉奖。 过了一段时间后有人反馈我修改了数据后查看详情发现数据没变但是我修改数据的时候提示我修改成功。擦难道是系统出bug了 登录服务器排查没发现有更新数据库、缓存的失败的信息但是发现个问题缓存是修改前的数据数据是修改后的数据那这种问题是怎么产生的呢 进一步分析发现缓存与数据库不一致的原因是并发导致的 先更新数据库再更新缓存 并发为什么能导致数据与缓存不一致呢我们接着分析我举个例子用户A与用户B同时修改一条数据 执行步骤 用户A更新数据库为1用户B更新数据库为2****用户B更新缓存2用户A更新缓存为1 从上面可以看出数据库为2缓存也应该为1这就造成了缓存与数据库不一致的现象 那如果我们先更新缓存再更新数据库呢 先更新缓存再更新数据库 执行步骤 用户A更新缓存为1用户B更新缓存2用户B更新数据库为2用户A更新数据库为1 从上面可以看出数据库为1缓存也应该为2还是造成了缓存与数据库不一致的现象 结论 无论是先更新数据库再更新缓存还是先更新缓存再更新数据库在并发访问修改一条数据的时候都会出现不一致的情况 想了想那不更新缓存了直接删除缓存。也就是数据库后更新后直接删除缓存。 在读取数据的时候查看缓存中有没有数据没有数据查询数据库然后再更新缓存。 这个策略有个名字Cache Aside 策略 中文旁路缓存策略 旁路缓存策略 Cache Aside旁路缓存策略是最常用的应用程序直接与「数据库、缓存」交互并负责对缓存的维护该策略又可以细分为「读策略」和「写策略」。 写策略的步骤 先更新数据库中的数据再删除缓存中的数据。 读策略的步骤 如果读取的数据命中了缓存则直接返回数据如果读取的数据没有命中缓存则从数据库中读取数据然后将数据写入到缓存并且返回给用户。 问题来了那我们是先更新数据库再删除缓存还是先删除缓存再更新数据库 先删除缓存再更新数据库 执行步骤 用户A删除缓存用户B查询缓存缓存中没有数据用户B查询数据库得到数据用户B更新缓存数据用户A更新数据库为最新的值 从结果看缓存的是旧值1数据库是最新值2在并发读写的场景下依然数据库跟缓存不一致。 先更新数据库再删除缓存 执行步骤 用户A查询缓存缓存未命中用户A查询数据库得到值为1用户B更新数据库值更新为2用户B删除缓存用户A把查询到的值1回写到缓存 从结果看缓存的是旧值1数据库是最新值2在并发读写的场景下依然数据库跟缓存不一致。 从理论上来分析先更新数据再删除缓存依然存在数据库与缓存不一致的情况但在实际中出现不一致的情况概率非常低。 因为缓存的写入速度远远大于写入数据库的速度为了以防万一再给缓存数据加一个过期时间如果真出现不一致的情况也最多在过期时间的这个区间不一致过期时间到了重新更新缓存也能到达最终一致性 方案选择 以下四种方案我们都分析了那我们到底用哪一种呢 先更新数据库再更新缓存先更新缓存再更新数据库先更新数据库再删除缓存先删除缓存再更新数据库 先说我的观点也是大厂的方案强烈推荐先更新数据库再删除缓存 原因如下 缓存的写入速度远远大于写入数据库的速度出现不一致的的概率很低设置过期时间如果真出现不一致的情况过期时间到期重新刷新缓存能达到最终一致性正常的情况缓存与数据强一致性也没那么高的要求如果真要达到强一致性系统吞吐量必要下降 题外话对于一致性的解决方案我对大厂的方案很感兴趣想了解他他们是怎么解决的。当进去后深入了解下使用的方案也是先更新数据库再删除缓存 最终一致性没必要强一致性原因跟上面三条差不多。 这样是不是很完美了嘛等等这种方案还有没有问题想想…看下图 更新数据库删除缓存是两个操作如果删除缓存失败了呢这种概率虽然很低那缓存中依然是旧值有没有什么方案解决这个问题呢 上面的四种方案无论是先操作数据库还是操作缓存都存在这种问题 问题原因知道了该怎么解决呢有两种方法 重试机制订阅 MySQL binlog再操作缓存 如何保证两个操作都执行成功 重试机制 引入消息中间件比如rabbitmq 如果应用删除缓存失败发送消息到mq然后从消息队列中重新读取数据然后再次删除缓存这个就是重试机制。当然如果重试超过的一定次数还是没有成功我们就需要向业务层发送报错信息了。如果删除缓存成功就要把数据从消息队列中移除避免重复操作否则就继续重试 订阅 MySQL binlog再操作缓存 引入canal中间件 canal译意为水道/管道/沟渠主要用途是基于 MySQL 数据库增量日志解析提供增量数据订阅和消费。 canal 工作原理 canal 模拟 MySQL slave 的交互协议伪装自己为 MySQL slave 向 MySQL master 发送dump 协议MySQL master 收到 dump 请求开始推送 binary log 给 slave (即 canal )canal 解析 binary log 对象(原始为 byte 流) 所以如果要想保证「先更新数据库再删缓存」策略第二个操作能执行成功我们可以使用「消息队列来重试缓存的删除」或者「订阅 MySQL binlog 再操作缓存」这两种方法有一个共同的特点都是采用异步操作缓存也可能存在短时间的不一致。 总结 如何保证数据库与缓存一致性先更新数据库再删缓存缓存设置一个过期时间 这种方案能适用95%以上的场景。 不知道你们在实际工作中你们的项目用的那种方案踩过哪些坑欢迎留言一起谈论。