redis的缓存

一.缓存简介

1.缓存

缓存（Cache）是计算机系统中用于 加快数据访问 的核心技术，通过在 高速存储介质 中临时存储数据的副本，减少对慢速存储层（如磁盘、数据库、长途服务）的直接访问，从而提升系统整体性能。
Redis 缓存是一种基于内存的高性能键值存储系统，专为加快数据访问、降低后端负载而设计。它通过将高频访问的数据存储在内存中，实现 微秒级响应，同时支持复杂数据结构和持久化机制，使其成为现代分布式系统中 核心缓存层 的办理方案。
2.redis作为数据库（MySQL）缓存的原因

在一个网站中，我们经常会使用关系型数据库(比如MySQL)来存储数据。关系型数据库固然功能强大，但是有⼀个很大的缺陷，就是性能不高(换而言之，举行一次查询操纵消耗的系统资源较多).
关系型数据库性能不高的原因：

• 数据库把数据存储在硬盘上，硬盘的IO速率并不快。尤其是随机访问。
  
• 如果查询不能掷中索引，就需要举行表的遍历，这就会大大增长硬盘IO次数。
  
• 关系型数据库对于SQL的执行会做⼀系列的解析，校验，优化工作。
  
• 如果是⼀些复杂查询，比如联合查询，需要举行笛卡尔积操纵，服从更是降低许多。
  
• …
  

因此，如果访问数据库的并发量比较高，对于数据库的压力是很大的，很轻易就会使数据库服务器宕机。
宕机的原因如下：
服务器每次处理⼀个请求，都是需要消耗⼀定的硬件资源的。所谓的硬件资源包括不限于CPU，内存，硬盘，网络带宽…⼀个服务器的硬件资源本身是有限的。⼀个请求消耗⼀份资源，请求多了，天然把资源就耗尽了。后续的请求没有资源可用，天然就无法正确处理。更严峻的还会导致服务器步伐的代码出现崩溃。
办理数据库能够承担更大的并发量，可以通过两个核心思绪：

• 开源：引入更多的呆板，部署更多的数据库实例，构成数据库集群。(主从复制，分库分表等…)
  
• 节流：引入缓存，使用其他的方式保存经常访问的热点数据，从而降低直接访问数据库的请求数量
  

此时Redis就是⼀个用来作为数据库缓存的常见方案：
Redis访问速率比MySQL快许多。或者说处理同⼀个访问请求，Redis消耗的系统资源比MySQL少许多。因此Redis能支持的并发量更大。

• Redis数据在内存中，访问内存比硬盘快许多。
  
• Redis只是⽀持简朴的key-value存储，不涉及复杂查询的那么多限定规则。
  

客户端访问业务服务器，发起查询请求

• 业务服务器先查询Redis，看想要的数据是否在Redis中存在
  
• 如果已经在Redis中存在了，就直接返回。此时不必访问MySQL了
  
• 如果在Redis中不存在，再查询MySQL
  
  
  
  

二.缓存更新策略

1.定期生成

每隔⼀定的周期(比如⼀天/⼀周/⼀个月)，对于访问的数据频次举行统计。挑选出访问频次最高的前N%的数据。
以Java小摊为栗子：
如果我没要拿到offer的话，我去摆一个Java小摊，那我肯定就要会炒米饭，炒河粉，炒米饭，炒面……那么此时我们就可以通过一定周次来对于食材的用来频次来举行统计，毕竟来买的人大部门都是住在附近的人、弟子或者是一些上班族，那么此时就可以通过食材的用量来知道使用频次最高的那些食材即可，这些食材也就会成为“热点食材”。
上述例子仅属于个人观点，而且我也不想去炒饭呀，倒也不是炒饭不好，而是我想去开发自己的玩意儿，感觉更故意思点，如果上述栗子有不切现实的地方，还盼望大佬们指正。
长处：
上述过程，现实上实现起来比较简朴，过程更可控(缓存中的存在的东西都是固定的)，方便排盘问题。
缺点：
实时性不敷，如果出现一些突发性变乱，有一些原来就不是热词的内容成为了热词，新的热词就可能反面的数据库带来较大的压力。
2.实时生成

先给缓存设定容量上限(可以通过Redis配置文件的 maxmemory 参数设定)接下来把用户每次查询分为以下两种环境：

• 如果在Redis查到了，就直接返回。
  
• 如果Redis中不存在，就从数据库查，把查到的结果同时也写⼊Redis。如果缓存已经满了(达到上限)，就触发缓存淘汰策略，把⼀些"相对不那么热门"的数据淘汰掉。按照上述过程，连续⼀段时间之后Redis内部的数据天然就是"热门数据"了。
  

3.内存淘汰策略

1）FIFO(First In First Out) 先进先出

把缓存中存在时间最久的(也就是先来的数据)淘汰掉。
2）LRU(Least Recently Used)淘汰最久未使用的

记录每个key的近来访问时间。把近来访问时间最老的key淘汰掉.
3）LFU(Least Frequently Used)淘汰访问次数最少的

记录每个key近来⼀段时间的访问次数，把访问次数最少的淘汰掉.
4）Random随机淘汰

从所有的key中抽取荣幸儿被随机淘汰掉。
明白上述几种淘汰策略（栗子纯属瞎编，无任何意思）：
想象你是个皇帝，有后宫美人三千。固然你是"真龙天子"，但是经常宠幸的妃子也就那么寥寥数⼈(精⼒有限)后宫美人三千，相当于数据库中的全量数据。经常宠幸的妃子相当于热点数据，是放在缓存的。今年选秀的一批新的小主，此中有⼀个被你看上了。宠信新⼈，天然就需要有旧⼈被冷落。到底谁是要被冷落的⼈呢?

• FIFO：皇后是开始受宠的。如今已经年老色衰了。皇后失宠。
  
• LRU：统计近来宠幸时间。皇后(⼀周前)，熹妃(昨天)，安允许(两周前)，华妃(一个月前)。华妃失宠.
  
• LFU：统计近来一个月的宠幸次数，皇后(3次)，熹妃(15次)，安允许(1次)，华妃(10次)。安允许失宠
  
• Random：随机挑一个妃子失宠
  

此处的淘汰策略可以自己实现，也可以使用redis的配置文件实现，因为redis提供了内置的淘汰策略：

• volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（近来最少使用）算法进性淘汰。
  
• allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（近来最少使用）算法举行淘汰
  
• volatile-lfu：4.0版本新增，当内存不足以容纳新写⼊数据时，在过期的key中，使用LFU算法举行删除key。
  
• allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法举行淘汰
  
• volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据.
  
• allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据
  
• volatile-ttl：在设置了过期时间的key中，根据过期时间举行淘汰，越早过期的优先被淘汰。(相当于FIFO，只不过是范围于过期的key)
  
• noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操纵会报错。
  

三.缓存相关问题简介

1.缓存预热

使用Redis作为MySQL的缓存的时候，当Redis刚刚启动，或者Redis大批key失效之后，此时由于Redis自身相当于是空着的，没啥缓存数据，那么MySQL就可能直接被访问到，从而造成较大的压力。因此就需要提前把热点数据准备好，直接写入到Redis中。使Redis可以尽快为MySQL撑起保护伞。
2.缓存穿透

访问的key在Redis和数据库中都不存在。此时如许的key不会被放到缓存上，后续如果仍然在访问该key，依然会访问到数据库。这就会导致数据库承担的请求太多，压力很大。这种环境称为缓存穿透。
产生的原因：
原因可能有几种：

• 业务设计不公道。比如缺少必要的参数校验环节，导致非法的key也被举行查询了。
  
• 开发/运维误操纵。不小心把部门数据从数据库上误删了。
  
• 黑客恶意攻击。
  

办理

• 针对要查询的参数举行严格的合法性校验。比如要查询的key是用户的手机号，那么就需要校验当前key是否满足⼀个合法的手机号的格式。
  
• 针对数据库上也不存在的key，也存储到Redis中，比如value就任意设成⼀个"".避免后续频仍访问数据库。
  
• 使用布隆过滤器先判定key是否存在，再真正查询。
  

3.缓存雪崩

短时间内大量的key在缓存上失效，导致数据库压力骤增，乃至直接宕机。原来Redis是MySQL的一个护盾，帮MySQL抵挡了许多外部的压力。一旦护盾突然失效了，MySQL自身承担的压力骤增，就可能直接崩溃。
产生原因
大规模key失效，可能性主要有两种：

• Redis宕机或者redis集群模式下大量节点宕机
  
• Redis上的大量的key同时过期。为啥会出现大量的key同时过期？这种很可能是短时间内在Redis上缓存了大量的key，而且设定了相同的过期时间。
  

办理

• 部署高可用的Redis集群，而且美满监控报警体系。
  
• 不给key设置过期时间或者设置过期时间的时候添加随机时间因子。
  

4.缓存击穿

相当于缓存雪崩的特殊环境。针对热点key，突然过期了，导致大量的请求直接访问到数据库上，乃至引起数据库宕机。
办理

• 基于统计的方式发现热点key，并设置永不过期。
  
• 举行必要的服务降级。比方访问数据库的时候使用分布式锁，限定同时请求数据库的并发数。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。