济南 网站设计公司,大数据营销是做什么的,皮肤科医生免费问诊,中国万网联系方式目录
缓存
Redis最主要的使用场景就是作为缓存
缓存的更新策略#xff1a;
1.定期生成
2.实时生成
面试重点#xff1a;
缓存预热#xff08;Cache preheating#xff09;#xff1a;
缓存穿透#xff08;Cache penetration#xff09;
缓存雪崩 (Cache avalan…目录
缓存
Redis最主要的使用场景就是作为缓存
缓存的更新策略
1.定期生成
2.实时生成
面试重点
缓存预热Cache preheating
缓存穿透Cache penetration
缓存雪崩 (Cache avalanche)
缓存击穿 (Cache breakdown)
分布式锁
分布式锁的基本实现
引入过期时间
引入校验Id:
引入lua脚本
引入watch dog看门狗
引入Redlock算法 缓存 核心思路就是把⼀些常见的数据放到触手可及(访问速度更快)的地方, 方便随时读取.
访问速度特别的快但由于存储空间是有限的所有我们只能存储“热点数据”频繁访问的数据在Redis中 俗称“二八定律”20%的热点数据可以应对80%的应用场景从而整体上的性能得到提升 Redis最主要的使用场景就是作为缓存
对应MySQL这种访问硬盘的数据库Redis是内存数据库Redis用做为MySQL的缓存 为什么MySQL性能不高 1.首先数据存储在硬盘上硬盘IO需要花费大量时间尤其是随机访问 2.如果查询中不能命中索引那么将需要表的遍历大大增加硬盘IO的次数 3.对应执行SQL需要一系列的解析校验等等工作 4.如果是一些复杂查询例如联合查询笛卡尔积之类的操作效率会很低............... 如果数据库并发量特别高那么它将会可能出现宕机出现故障罢工了不做了的情况
如何解决 1.开源增加多个设备部署更多的数据库机器构成数据库集群 2.节流引入缓存访问的时候尽量访问缓存内的数据从而降低直接访问数据库的请求数量 实际开发中往往是俩种方法结合起来使用 Redis为什么可以作为MySQL的缓存 Redis访问速度比MySQL快很多并且处理一个访问请求Redis消耗的资源比MySQL少很多因此Redis支持更大的并发量 1.Redis数据在内存并且访问速度比硬盘快很多 2.Redis只支持简单的KEY-VALUE 存储不涉及很多复杂查询方法手段 业务服务器先查询 Redis, 看想要的数据是否在 Redis 中存在. 如果已经在 Redis 中存在了, 就直接返回. 此时不必访问 MySQL 了. 如果在 Redis 中不存在, 再查询 MySQL. 缓存的更新策略
一个重要问题那么多数据哪些数据才是我们需要的热点数据呢
1.定期生成
会将所有访问的数据以日志的形式给记录下来最后挑选出频率前%N的数据作为“热点数据”
此处的数据可以按照每天/周/月去更新热点数据
2.实时生成
如果在Redis查找到了那么将直接返回如果在Redis没有查找到那么从数据库查找查找完并且写入Redis中
那么经过这样一段时间内缓存的数据肯定会存储满那么Redis也引入了对应的策略--------------内存淘汰机制
通用的淘汰机制有以下机制
FIFO (First In First Out) 先进先出 把缓存中存在时间最久的 (也就是先来的数据) 淘汰掉. LRU (Least Recently Used) 淘汰最久未使⽤的 记录每个 key 的最近访问时间. 把最近访问时间最⽼的 key 淘汰掉. LFU (Least Frequently Used) 淘汰访问次数最少的 记录每个 key 最近⼀段时间的访问次数. 把访问次数最少的淘汰掉. Random 随机淘汰 从所有的 key 中抽取幸运⼉被随机淘汰掉. 在Redis中已经实现好了以上类似机制 整体来说 Redis 提供的策略和我们上述介绍的通用策略是基本⼀致的. 只不过 Redis 这里会针对 过期 key 和 全部 key 做分别处理.
面试重点
缓存预热Cache preheating
1.定期生成的数据这种情况不涉及缓存预热
2.实时生成 Redis服务器首次接入连接之后是没有数据的此时所有的请求将在MySQL中就怕此时MySQL没有抗住这么多请求挂了那么随之时间的推移Redis上的数据慢慢越来越多MySQL承担的压力就会小很多
缓存预热就是解决上述问题 将定期生成和实时生成结合一下先通过“离线”的方式通过统计的途径先找到一些热点数据这些数据并一定精准有就行导入到Redis中就能帮助MySQL承担很大的压力随之时间的推移热点数据会逐渐调整来使用当前情况 缓存穿透Cache penetration
在查询某个key的时候在Redis中没有在MySQL中也没有那么这么key肯定不会更新到Redis中~ 但是这个查询没有接连着查询了多次依然会给MySQL造成一些压力
为什么出现这种情况
业务设计不合理. 比如缺少必要的参数校验环节, 导致非法的 key 也被进行查询了.开发/运维误操作. 不小心把部分数据从数据库上误删了.黑客恶意攻击.
解决
针对要查询的参数进行严格的合法性校验. 比如要查询的 key 是用户的手机号, 那么就需要校验当前key 是否满足一个合法的手机号的格式.针对数据库上也不存在的 key , 也存储到 Redis 中比如 value 就随便设成一个 . 避免后续频繁访问数据库使用布隆过滤器先判定 key 是否存在, 再真正查询. 缓存雪崩 (Cache avalanche)
在短时间内Redis上大规模的key失效导致缓存命中率陡然下降让MySQL的压力迅游变大导致宕机~
为何产生
1.Redis挂了
2.Redis没有挂但是可能之前给很多key设置的过期时间相同一下子全过期自动删除了
解决
部署高可用的 Redis 集群, 并且完善监控报警体系.不给 key 设置过期时间 或者 设置过期时间的时候添加随机时间因子. 缓存击穿 (Cache breakdown)
相当于缓存雪崩的特殊情况针对Redis热点key全部过期了导致大量的请求直接访问到MySQ中引起数据库宕机
基于统计的方式发现热点 key, 并设置永不过期.进行必要的服务降级. 例如访问数据库的时候使用分布式锁, 限制同时请求数据库的并发数. 分布式锁
在一个分布式系统当中会涉及到多个节点访问同一个公共资源的情况下此时就需要通过“锁”来进行互斥避免出现“线程安全”的问题
像Java中的synchronized 这种锁只能在当前进程中生效在分布式这种多个进程多个主机的场景下就不能使用了‘
分布式锁的基本实现
实现思路通过设置一个键值对来标识锁的状态
举例买票的例子 此时客户端1查询001车 还有1张车票 在即将执行1-0 过程前 客户端2也执行查询余票 发现还有一张那么客户端2也执行1-0 那么这出现“超卖” 的情况俩个人都买到票 加锁 此时, 如果 买票服务器1 尝试买票, 就需要先访问 Redis, 在 Redis 上设置⼀个键值对. 比如 key 就是车次, value 随便设置个值 (比如 1). 如果发现操作成功那么就可以视为当前没有节点对001车次加锁那么就可以进行数据库的读写操作完成之后就可以吧这个key删除相当于解锁 如果服务器1在操作数据库时候服务器2也想买票那么它在给Redis新增key的时候就会发现此时车次的key已经存在就可以认为其他服务器此时正在持有锁那么服务器2就可以等待或者放弃~ Redis中的setnx刚刚好就行对应此场景当key不存在才可以创建成功如果存在那么将失败 ~
此时如果某个服务器加锁成功但意外发生了服务器崩溃了没有执行解锁操作删除操作那么就导致其他服务器没有获取到锁
引入过期时间
可以设置key的过期时间让这个锁持有多久如果超过一定时间那么将自动释放;
使用set ex nx 命令在设置锁的同时加入过期时间 注意这是一条命令 不能写成 setnx expire 此时是俩条命令就有可能造成原子性仍然会出现无法正确释放锁的问题 所谓的加锁就是在Redis上执行setnx生成一个key 解锁就是删除这个key
那么有没有可能会出现服务器1执行了加锁操作而服务器2执行了解锁 那么是有可能的
引入校验Id:
需要引入一点校验机制
1.给服务器编号每个服务器有一个自己的身份标识
2.进行加锁的时候设置key-value 对应要针对的哪个资源加锁比如车次value存储刚才服务器的编号 例如“001:1” -“001服务器1”
这样就可以在删除key的时候校验当前的key是否是当初加锁的服务器避免删除错误~ 在解锁的时候 1.先查询判断是否删除 2. 才进行删除
此时这个是俩步操作并不是原子的就有可能出现问题
引入lua脚本
很多程序里面都支持内嵌脚本语音.Redis支持Lua语音作为内嵌脚本~
if redis.call(get,KEYS[1]) ARGV[1] then
return redis.call(del,KEYS[1])
else
1 2 3return 0
end; 过期时间续约问题可能存在
在给key加锁的时候设置它的过期时间那么设置多久呢才是比较合适
设置时间短那么可能在业务逻辑还没执行完就释放锁了设置时间长就可以导致锁释放不及时的可能
更好的是能够去进行“动态续约”
引入watch dog看门狗
本质上就是在加锁的服务器上的一个单独的线程通过这个线程来对锁过期时间进行一个“续约” ❤ 举个具体的例子: 初始情况下设置过期时间为 10s. 同时设定看门狗线程每隔 3s 检测⼀次. 那么当 3s 时间到的时候, 看门狗就会判定当前任务是否完成. 如果任务已经完成, 则直接通过 lua 脚本的方式, 释放锁(删除 key). 如果任务未完成, 则把过期时间重写设置为 10s. (即 续约) 使用Redis作为分布式锁有没有可能Redis自身挂了
那么是很有可能的
Redis一般是以集群至少也是主从的形式而不是单机的方式去部署的 服务器1向它的master节点就行加锁操作这个数据刚写入主节点主节点挂了从节点就会新的主节点 由于主节点和从节点之间的数据是同步的但是有延迟的 那么刚才写入的key还没有被新的主节点接收此时相当于服务器1就没有成功进行加上锁 但是服务器2仍然可以进行去加上锁 引入Redlock算法 由于主节点和主节点之间数据都是一致的相互是备份的关系 在进行加锁的时候会按照一定的顺序针对这组Redis都进行加锁 如果某个节点加不上锁并没有关系可能是Redis挂了继续给下一个节点加锁即可 如果此时key加锁成功的节点个数占总的一半那么可视为加锁成功 同时解锁的时候会把上述的节点都需要解锁~ 简而言之, Redlock 算法的核心就是, 加锁操作不能只写给⼀个 Redis 节点, 而要写个多个!! 分布式系统中任何⼀个节点都是不可靠的. 最终的加锁成功结论是 少数服从多数的.
