缓存同步如何保证缓存一致性缓存误用
Posted Linkoffer
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了缓存同步如何保证缓存一致性缓存误用相关的知识,希望对你有一定的参考价值。
segmentfault.com/a/1190000015804406
缓存误用
服务1和服务2约定好key和value,通过缓存传递数据
服务1将数据写入缓存,服务2从缓存读取数据,达到两个服务通信的目的
1、数据管道,数据通知场景,MQ更加适合
(1)MQ是互联网常见的逻辑解耦,物理解耦组件,支持1对1,1对多各种模式,非常成熟的数据通道,而cache反而会将service-A/B/C/D耦合在一起,大家要彼此协同约定key的格式,ip地址等
(2)MQ能够支持push,而cache只能拉取,不实时,有时延
(3)MQ天然支持集群,支持高可用,而cache未必
(4)MQ能支持数据落地,cache具备将数据存在内存里,具有“易失”性,当然,有些cache支持落地,但互联网技术选型的原则是,让专业的软件干专业的事情:nginx做反向代理,db做固化,cache做缓存,mq做通道
(1)大家要彼此协同约定key的格式,ip地址等,耦合
服务先读缓存,缓存命中则返回
缓存不命中,再读数据库
答:如果缓存挂掉,所有的请求会压到数据库,如果未提前做容量预估,可能会把数据库压垮(在缓存恢复之前,数据库可能一直都起不来),导致系统整体不可服务。
答:提前做容量预估,如果缓存挂掉,数据库仍能扛住,才能执行上述方案。
服务提供方缓存,向调用方屏蔽数据获取的复杂性(这个没问题)
服务调用方,也缓存一份数据,先读自己的缓存,再决定是否调用服务(这个有问题)
1、调用方需要关注数据获取的复杂性(耦合问题)
2、更严重的,服务修改db里的数据,淘汰了服务cache之后,难以通知调用方淘汰其cache里的数据,从而导致数据不一致(带入一致性问题)
3、有人说,服务可以通过MQ通知调用方淘汰数据,额,难道下游的服务要依赖上游的调用方,分层架构设计不是这么玩的(反向依赖问题)
画外音:可能需要服务A和服务B提前约定好了key,以确保不冲突,常见的约定方式是使用namespace:key的方式来做key。
1、服务与服务之间不要通过缓存传递数据
缓存,究竟是淘汰,还是修改?
答:
(1)朴素类型的数据,例如:int
(1)淘汰某个key,操作简单,直接将key置为无效,但下一次该key的访问会cache miss
答:
(1)朴素类型的数据,直接set修改后的值即可
答:仍然视情况而定。
假设,缓存里存了某一个用户uid=123的余额是money=100元,业务场景是,购买了一个商品pid=456。
(1)去db查询pid的价格是50元
为了避免一次cache miss,需要额外增加若干次db与cache的交互,得不偿失。
假设,缓存里存了某一个用户uid=123的余额是money=100元,业务场景是,需要扣减30元。
(1)从cache查询get用户的余额是100元
为了避免一次cache miss,需要额外增加若干次cache的交互,以及业务的计算,得不偿失。
假设,缓 存里存了某一个用户uid=123的余额是money=100元,业务场景是,余额要变为70元。
分析:如果修改缓存,需要:
(1)到cache设置set用户的余额是70
修改缓存成本很低。
结论:此时,可以选择修改缓存。当然,如果选择淘汰缓存,只会额外增加一次cache miss,成本也不高。
总结:
允许cache miss的KV缓存写场景:
大部分情况,修改value成本会高于“增加一次cache miss”,因此应该淘汰缓存
如果还在纠结,总是淘汰缓存,问题也不大
先操作数据库,还是先操作缓存?
这里分了两种观点,Cache Aside Pattern的观点、沈老师的观点。下面两种观点分析一下。
Cache Aside Pattern
什么是“Cache Aside Pattern”?
答:旁路缓存方案的经验实践,这个实践又分读实践,写实践。
对于读请求
先读cache,再读db
如果,cache hit,则直接返回数据
如果,cache miss,则访问db,并将数据set回缓存
(1)先从cache中尝试get数据,结果miss了
(2)再从db中读取数据,从库,读写分离
(3)最后把数据set回cache,方便下次读命中
对于写请求
先操作数据库,再淘汰缓存(淘汰缓存,而不是更新缓存)
如上图:
(1)第一步要操作数据库,第二步操作缓存
(2)缓存,采用delete淘汰,而不是set更新
Cache Aside Pattern为什么建议淘汰缓存,而不是更新缓存?
答:如果更新缓存,在并发写时,可能出现数据不一致。
如上图所示,如果采用set缓存。
在1和2两个并发写发生时,由于无法保证时序,此时不管先操作缓存还是先操作数据库,都可能出现:
(1)请求1先操作数据库,请求2后操作数据库
(2)请求2先set了缓存,请求1后set了缓存
导致,数据库与缓存之间的数据不一致。
所以,Cache Aside Pattern建议,delete缓存,而不是set缓存。
Cache Aside Pattern为什么建议先操作数据库,再操作缓存?
答:如果先操作缓存,在读写并发时,可能出现数据不一致。
如上图所示,如果先操作缓存。
在1和2并发读写发生时,由于无法保证时序,可能出现:
(1)写请求淘汰了缓
(2)写请求操作了数据库(主从同步没有完成)
(3)读请求读了缓存(cache miss)
(4)读请求读了从库(读了一个旧数据)
(5)读请求set回缓存(set了一个旧数据)
(6)数据库主从同步完成
导致,数据库与缓存的数据不一致。
所以,Cache Aside Pattern建议,先操作数据库,再操作缓存。
Cache Aside Pattern方案存在什么问题?
答:如果先操作数据库,再淘汰缓存,在原子性被破坏时:
(1)修改数据库成功了
(2)淘汰缓存失败了
导致,数据库与缓存的数据不一致。
个人见解:这里个人觉得可以使用重试的方法,在淘汰缓存的时候,如果失败,则重试一定的次数。如果失败一定次数还不行,那就是其他原因了。比如说redis故障、内网出了问题。
关于这个问题,沈老师的解决方案是,使用先操作缓存(delete),再操作数据库。假如删除缓存成功,更新数据库失败了。缓存里没有数据,数据库里是之前的数据,数据没有不一致,对业务无影响。只是下一次读取,会多一次cache miss。这里我觉得沈老师可能忽略了并发的问题,比如说以下情况:
一个写请求过来,删除了缓存,准备更新数据库(还没更新完成)。
然后一个读请求过来,缓存未命中,从数据库读取旧数据,再次放到缓存中,这时候,数据库更新完成了。此时的情况是,缓存中是旧数据,数据库里面是新数据,同样存在数据不一致的问题。
如图:
不一致解决场景及解决方案
先回顾下,无缓存时,数据库主从不一致问题。
(1)主库一个写请求(主从没同步完成)
(2)从库接着一个读请求,读到了旧数据
(3)最后,主从同步完成
再看,引入缓存后,缓存和数据库不一致问题。
(1+2)先一个写请求,淘汰缓存,写数据库
可以看到,这里提到的缓存与数据库数据不一致,根本上是由数据库主从不一致引起的。当主库上发生写操作之后,从库binlog同步的时间间隔内,读请求,可能导致有旧数据入缓存。
选择性读主
可以利用一个缓存记录必须读主的数据。
(1)写主库
(2)将哪个库,哪个表,哪个主键三个信息拼装一个key设置到cache里,这条记录的超时时间,设置为“主从同步时延”
这是要读哪个库,哪个表,哪个主键的数据呢,也将这三个信息拼装一个key,到cache里去查询,如果,
(1)cache里有这个key,说明1s内刚发生过写请求,数据库主从同步可能还没有完成,此时就应该去主库查询。并且把主库的数据set到缓存中,防止下一次cahce miss。
(2)cache里没有这个key,说明最近没有发生过写请求,此时就可以去从库查询
进程内缓存
如上图,整个访问流程要经过1,2,3,4四个步骤。
如上图,整个访问流程只要经过1,2两个步骤。
而进程内缓存,如上图,如果数据缓存在站点和服务的多个节点内,数据存了多份,一致性比较难保障。
答:保障进程内缓存一致性,有三种方案。
可以通过单节点通知其他节点。如上图:写请求发生在server1,在修改完自己内存数据与数据库中的数据之后,可以主动通知其他server节点,也修改内存的数据。如下图:
可以通过MQ通知其他节点。如上图,写请求发生在server1,在修改完自己内存数据与数据库中的数据之后,给MQ发布数据变化通知,其他server节点订阅MQ消息,也修改内存数据。
为了避免耦合,降低复杂性,干脆放弃了“实时一致性”,每个节点启动一个timer,定时从后端拉取最新的数据,更新内存缓存。在有节点更新后端数据,而其他节点通过timer更新数据之间,会读到脏数据。
可以看到,站点与服务的进程内缓存,实际上违背了分层架构设计的无状态准则,故一般不推荐使用。
只读数据,可以考虑在进程启动时加载到内存。
画外音:此时也可以把数据加载到redis / memcache,进程外缓存服务也能解决这类问题。
极其高并发的,如果透传后端压力极大的场景,可以考虑使用进程内缓存。
例如,秒杀业务,并发量极高,需要站点层挡住流量,可以使用内存缓存。
一定程度上允许数据不一致业务。
例如,有一些计数场景,运营场景,页面对数据一致性要求较低,可以考虑使用进程内页面缓存。
以上是关于缓存同步如何保证缓存一致性缓存误用的主要内容,如果未能解决你的问题,请参考以下文章