kafka吞吐量单位，终于搞明白了

缓存维护方案一

如果是一读&＃xff08;线程B&＃xff09;一写&＃xff08;线程A&＃xff09;操作&＃xff0c;「先操作缓存&＃xff0c;再操作数据库」。流程图如下所示&＃xff1a;

• 1.线程A发起一个写操作&＃xff0c;第一步del cache

• 2.线程A第二步写入新数据到DB

• 3.线程B发起一个读操作&＃xff0c;cache miss缓存失效了。

• 4.线程B从DB获取最新数据

• 5.线程B执行set cache&＃xff0c;把从DB读到的数据&＃xff0c;更新到缓存。

「这样看&＃xff0c;没啥问题」。我们再看第二个流程图&＃xff0c;如下&＃xff1a;

• 1.线程A发起一个写操作&＃xff0c;第一步del cache

• 2.此时线程B发起一个读操作&＃xff0c;cache miss

• 3.线程B继续读DB&＃xff0c;读出来一个老数据

• 4.然后老数据设置入cache

• 5.线程A写入DB最新的数据

OK&＃xff0c;酱紫&＃xff0c;就有问题了吧&＃xff0c;老数据入到缓存了&＃xff0c;「每次读都是老数据啦&＃xff0c;缓存与数据与数据库数据不一致了」。

缓存维护方案二

上个方案是一读一写&＃xff0c;如果是双写操作&＃xff0c;「先操作缓存&＃xff0c;再操作数据库」&＃xff0c;会怎么样呢&＃xff1f;

• 1.线程A发起一个写操作&＃xff0c;第一步set cache

• 2.线程A第二步写入新数据到DB

• 3.线程B发起一个写操作&＃xff0c;set cache

• 4.线程B第二步写入新数据到DB

「这样看&＃xff0c;也没啥问题。」&＃xff0c;但是有时候可能事与愿违&＃xff0c;我们再看第二个流程图&＃xff0c;如下:

• 1.线程A发起一个写操作&＃xff0c;第一步set cache

• 2.线程B发起一个写操作&＃xff0c;第一步set cache

• 3.线程B写入数据库到DB

• 4.线程A写入数据库到DB

执行完后&＃xff0c;缓存保存的是B操作后的数据&＃xff0c;数据库是A操作后的数据&＃xff0c;「缓存和数据库数据不一致」。

缓存维护方案三

一写&＃xff08;线程A&＃xff09;一读&＃xff08;线程B&＃xff09;操作&＃xff0c;「先操作数据库&＃xff0c;再操作缓存」。

• 1.线程A发起一个写操作&＃xff0c;第一步write DB

• 2.线程A第二步del cache

• 3.线程B发起一个读操作&＃xff0c;cache miss

• 4.线程B从DB获取最新数据

• 5.线程B同时set cache

「有些朋友可能认为&＃xff0c;在第2步删除缓存之前&＃xff0c;线程B读过来呢&＃xff1f;这时候&＃xff0c;读到的是缓存老数据&＃xff0c;这个可以认为是正常业务逻辑呀&＃xff0c;下次再读取就是正确数据了。」

这种方案**「没有明显的并发问题」&＃xff0c;但是有可能「步骤二删除缓存失败」&＃xff0c;虽然概率比较小&＃xff0c;「优于方案一和方案二」**&＃xff0c;平时工作中也是使用方案三。

综上对比&＃xff0c;我们一般采用方案三&＃xff0c;但是有没有完美全解决方案三的弊端的方法呢&＃xff1f;

缓存维护方案四

这个是方案三的改进方案&＃xff0c;都是先操作数据库再操作缓存&＃xff0c;我们来看一下流程图&＃xff1a;

通过数据库的**「binlog」来「异步淘汰key」&＃xff0c;以mysql为例 可以「使用阿里的canal将binlog日志采集发送到MQ队列」里面&＃xff0c;然后「通过ACK机制 确认处理」** 这条更新消息&＃xff0c;删除缓存&＃xff0c;保证数据缓存一致性。

但是呢还有个问题&＃xff0c;「如果是主从数据库呢」&＃xff1f;

缓存维护方案五

主从DB问题&＃xff1a;因为主从DB同步存在延时时间。如果删除缓存之后&＃xff0c;数据同步到备库之前已经有请求过来时&＃xff0c;「会从备库中读到脏数据」&＃xff0c;如何解决呢&＃xff1f;解决方案如下流程图&＃xff1a;

缓存维护总结

综上所述&＃xff0c;在分布式系统中&＃xff0c;缓存和数据库同时存在时&＃xff0c;如果有写操作的时候&＃xff0c;「先操作数据库&＃xff0c;再操作缓存」。如下&＃xff1a;

• 1.读取缓存中是否有相关数据
• 2.如果缓存中有相关数据value&＃xff0c;则返回
• 3.如果缓存中没有相关数据&＃xff0c;则从数据库读取相关数据放入缓存中key->value&＃xff0c;再返回
• 4.如果有更新数据&＃xff0c;则先更新数据库&＃xff0c;再删除缓存
• 5.为了保证第四步删除缓存成功&＃xff0c;使用binlog异步删除
• 6.如果是主从数据库&＃xff0c;binglog取自于从库
• 7.如果是一主多从&＃xff0c;每个从库都要采集binlog&＃xff0c;然后消费端收到最后一台binlog数据才删除缓存

笔者福利

以下是小编自己针对马上即将到来的金九银十准备的一套“面试宝典”&＃xff0c;不管是技术还是HR的问题都有针对性的回答。

有了这个&＃xff0c;面试踩雷&＃xff1f;不存在的&＃xff01;

需要这套“面试宝典”的&＃xff0c;点击这里即可免费获取&＃xff01;回馈粉丝&＃xff0c;诚意满满&＃xff01;&＃xff01;&＃xff01;