分布式缓存复述是一种支持键值等多种数据结构的存储系统。可用于缓存,事件发布或订阅,高速队列等多种场景.Redis使用ANSI C语言编写,提供字符串(字符串),哈希散列,列表(列表),集合结构(组,排序),流(流)等数据类型的直接存取。数据读写基于内存,同时可持久化到磁盘。
在我们做开发的过程中经常会用到复述,小编在这里就复述,谈谈,我们使用过程中经常会遇到的几个问题吧。
<强>一、复述的过期策略以及内存淘汰机制
这个问题相当重要,到底复述,有没用到家,这个问题就可以看出来。
比如你复述,只能存5克数据,可是你写了10 g中,那会删5 g的数据。怎么删的,这个问题思考过么?
还有,你的数据已经设置了过期时间,但是时间到了,内存占用率还是比较高,有思考过原因么?
回答:复述,采用的是定期删除+惰性删除策略。
为什么不用定时删除策略
定时删除,用一个定时器来负责监视键,过期则自动删除。虽然内存及时释放,但是十分消耗CPU资源。
在大并发请求下,CPU要将时间应用在处理请求,而不是删除关键,因此没有采用这一策略。
定期删除+惰性删除是如何工作
定期删除,复述,默认每个100 ms检查,是否有过期的关键,有过期关键则删除。
需要说明的是,复述,不是每100个女士将所有的关键检查一次,而是随机抽取进行检查(如果每隔100毫秒,全部关键进行检查,复述,岂不是卡死)。
因此,如果只采用定期删除策略,会导致很多到关键时间没有删除。于是,惰性删除派上用场。
也就是说在你获取某个关键的时候,复述,会检查一下,这个关键如果设置了过期时间,那么是否过期了?如果过期了此时就会删除。
采用定期删除+惰性删除就没其他问题了么?
不是的,如果定期删除没删除关键。然后你也没即时去请求键,也就是说惰性删除也没生效。这样,复述的内存会越来越高。那么就应该采用内存淘汰机制。
在复述。会议中有一行配置:
<强> # maxmemory-policy volatile-lru
该配置就是配内存淘汰策略的(什么,你没配过?好好反省一下自己):
◆noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。应该没人用吧。
◆allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的关键。推荐使用,目前项目在用这种。
◆allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个关键。应该也没人用吧,你不删最少使用钥匙,去随机删。
◆volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的关键。这种情况一般是把复述,既当缓存,又做持久化存储的时候才用。不推荐。
◆volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个关键。依然不推荐。
◆volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的关键优先移除。不推荐。
PS:如果没有设置的钥匙,到期不满足先决条件(先决条件);那么volatile-lru, volatile-random和volatile-ttl策略的行为,和noeviction(不删除)基本上一致。
<强>二、复述和数据库双写一致性问题
一致性问题是分布式常见问题,还可以再分为最终一致性和强一致性。数据库和缓存双写,就必然会存在不一致的问题。
答这个问题,先明白一个前提。就是如果对数据有强一致性要求,不能放缓存。我们所做的一切,只能保证最终一致性。
另外,我们所做的方案从根本上来说,只能说降低不一致发生的概率,无法完全避免。因此,有强一致性要求的数据,不能放缓存。
回答:首先,采取正确更新策略,先更新数据库,再删缓存。其次,因为可能存在删除缓存失败的问题,提供一个补偿措施即可,例如利用消息队列。
<强>三,如何应对缓存穿透和缓存雪崩问题
这两个问题,说句实在话,一般中小型传统软件企业,很难碰到这个问题。如果有大并发的项目,流量有几百万左右。这两个问题一定要深刻考虑。
缓存穿透,即* * *故意去请求缓存中不存在的数据,导致所有的请求都怼到数据库上,从而数据库连接异常。
