公司做网站的价格几千元,预付网站制作费怎么做凭证,自动化科技产品网站建设,wordpress shortcode土豆 视频目录 前言 Redis支持哪些数据类型 五种核心类型 Zset为什么用跳表不用红黑树 #xff1f; Redis常见的应用场景#xff1f; 如何检测Redis的连通性#xff1f; 如何设置key的过期时间#xff1f; Redis为什么是单线程模型#xff1f; Redis里的IO多路复用是什…目录 前言 Redis支持哪些数据类型 五种核心类型  Zset为什么用跳表不用红黑树  Redis常见的应用场景  如何检测Redis的连通性 如何设置key的过期时间  Redis为什么是单线程模型  Redis里的IO多路复用是什么  RDB的持久化机制有哪些  AOF的重写机制是怎么样的  Redis的过期删除策略是怎么样的 Redis处理缓存雪崩的问题 Redis的主从复制是怎么回事 介绍一下Redis哨兵 Redis集群是干什么用的 Redis的哈希槽是怎么回事  Redis集群会有操作丢失吗  如何理解Redis的事务和MySQL的事务有什么区别 什么是缓存穿透、缓存雪崩、缓存击穿  缓存穿透 缓存雪崩 缓存击穿 Redis和MySQL如何保证双写一致性 Redis的“bigkey”问题 前言 Redis是一个高性能的key-value的内存数据库 在内存上的数据会随着掉电而通通消失所以就有了不同的持久化的方式搞到硬盘上。Redis没有关系型数据库那种复杂查询的功能而换来的是简单易用和高性能~~ Redis支持哪些数据类型 五种核心类型  StringHashmapListSetZset  后续新增了一些数据类型~ Bitmap通过二进制位表示某个数是否存在Bitfield把字符串当作位图进行位操作Hyperloglog基于位图实现计数效果Geospatial地理信息存储经纬度并可以进行一些空间计算Stream消息队列 Zset为什么用跳表不用红黑树  跳表的插入、删除、查询的时间复杂度一样是O(logN)与红黑树一样。但是跳表更简单不需要重新平衡这种操作 Redis常见的应用场景  缓存用来保存常见的热点数据减少数据库的压力计数器统计点击次数、收藏、点赞次数等排行榜可以基于Zset简单实现分布式会话使用Redis存储会话信息可以让用户访问到系统的不同模块的时候都使用同一个公共会话分布式锁对于分布式的一种并发控制手段可以基于Redis来实现上篇文章有详细展开消息队列Redis自身支持Stream数据类型可以作为简单的消息队列使用 如何检测Redis的连通性 给服务端发送一个 ping 通顺的话就会收到 pong  如何设置key的过期时间  可以在set key的时候通过EX选项指定过期时间也可以再使用expire对已存在的key设置过期时间  Redis为什么是单线程模型  Redis内部逻辑较为简单大部分的性能瓶颈都是出现在IO或内存上很少是CPU。因此使用多线程还没多大收益还容易引入线程安全问题 从Redis6.0开始Redis引入多线程此时它也只是使用多线程去处理网络请求协议解析真正执行Redis命令的仍然是单线程完成这样可以提高IO处理效率  Redis里的IO多路复用是什么  Redis主要是基于Linux提供的epoll机制来完成IO多路复用之前文章详细讲述过 所谓IO多路复用其实就是一个线程来管理多个 socket 并按需激活线程 |  假如在同一个单位时间内有多个Redis客户端的请求到来了..... | 使用传统的方式是给每一个客户端连接开一个线程但是大部分的客户端不会频繁的给你      传输即多数是空闲线程不活跃 所以搞一堆线程不如就用一个线程来处理反正并    发量不会太高而且处理速度又飞快 上述的操作被Linux封装好了就是IO多路复用 在Linux中有三种实现方式 selectpollepoll epoll是最新也是最高效的版本之前文章有详细讲述这里浅浅谈一下 epoll在内核维护了一个红黑树来管理这些socket并且每一个节点都关联了一个事件回调当系统内核感知到网卡收到数据进一步判定这个数据是给哪一个socket的随之调用对应的回调函数进一步唤醒用户线程来处理这个数据 RDB的持久化机制有哪些  RDB和AOF两种 RDB RDB是一个紧凑的二进制文件代表Redis某个时间的数据快照。适合备份全量复制的场景。Redis加载RDB文件来恢复数据远快于AOF但是RDB也没办法做到实时持久化。因为每次的bgsave都需要fork全量复制对于cpu和硬盘的负荷大此外RDB文件使用特定的二进制格式保存Redis版本演进过程中有多个RDB版本兼容性可能有冲突 AOF AOF记录所有写入Redis的命令文本方式因此AOF的实时性高适合在Redis宕机的时候恢复AOF提供了重写功能可以定期对AOF文件进行重写取出冗余命令减小AOF大小由于每次的命令都要同步到AOF文件中所以会有一定的写入延迟AOF文件是文本类型的数据比较大如果AOF的文件过大就会导致恢复速度比较慢了 AOF的重写机制是怎么样的  Redis在后台启动一个AOF重写进程 在AOF重写过程中Redis继续处理客户端请求并将这份数据同时保存到旧AOF文件以及一个缓冲区新的AOF文件会遍历内存中的数据状态只保留数据的最后状态。并与缓冲区共同生成一份完整的AOF文件用新的AOF文件来代替旧的AOF文件 Redis的过期删除策略是怎么样的 惰性过期 只有当访问一个key的时候才能判断他是否过期过期就清除。 这种策略方式可以节省CPU资源但是会有可能出现大量过期的key未被再次访问导致占用大量内存 定期过期 每个一段时间会扫描一定数量的数据库expires字典中一定数量的key并清除已过期的key。 expire字典中会保存所有设置了过期时间的key的过期时间数据其中key是指向某个键的指针value是该键的毫秒精度的UNIX时间戳表示过期时间 Redis中则是同时使用了这两种策略 每隔100ms就随机抽取一定数量的key来检查和删除在获取key的时候检查一下是否过期过期就删除 Redis处理缓存雪崩的问题 首先对于定期删除来说Redis会注册一个定时器每个一定时间就触发一次 在删除的时候会根据事先统计好的过期key的个数来决定后续策略 如果过期key的个数超过总key的25%就会让Redis持续删除过期key直到最大删除时间默认25ms但即使如此有些对性能要求高的常见仍然会因为阻塞25ms导致性能下降 解决方案可以在过期时间上加上随机值使过期时间分散一点降低触发这个25%阈值 Redis的主从复制是怎么回事 其实就是为了保证咱redis的高可用减少单个节点的负载具体流程之前文章讲述过 Redis主从复制https://blog.csdn.net/Obto_/article/details/135946296 介绍一下Redis哨兵 之前文章有详细讲述感兴趣的可以看看这篇文章Redis哨兵https://blog.csdn.net/Obto_/article/details/135964383 Redis Sentinel是Redis的高可用的实现方案在实际的生产环境中对整个系统的高可用提升是非常有帮助的当主从复制结构中某个节点宕机之后哨兵能够自动发现故障并完成故障转移 如果是主节点故障哨兵之中会互相协商哨兵不只一个当大多数哨兵节点达成主节点宕机的结果后就会在哨兵之中推举出一个领导节点来自动完成故障转转移的工作同时将这个变化通知给Redis客户端这个过程是全自动的不需要人工介入 Redis集群是干什么用的 之前的文章有详细讲述感兴趣的可以看看这篇文章 Redis集群https://blog.csdn.net/Obto_/article/details/136176895 Redis集群引入多组Master/Slave每一组Master/Slave存储数据全集的一部分从而构成更大的整体解决单个Master/Slave能够达到的性能上限能够存储更多的数据 好比一个30T的资源放在一个硬盘放不下就可以放在3个10T的硬盘上  Redis的哈希槽是怎么回事  在Redis集群中要合理的分配各个主节点的资源所以就有了不同的hash方式将数据映射到对应的分片中 第一种就是直接hash 一个 N N为分片的总数这样能够保证数据随机分配但是一旦出现数据扩容的情况N发生了变化此时之前的映射关系全部作废扩容的代价很大 第二种就是一致性hash统一hash一个数这样能解决上述因扩容而导致的映射关系被破坏但是会导致数据的不均匀 因此哈希槽分区算法就出来了 哈希槽分区算法 将所有的key都映射到16284(2^14) 个槽位上再把这些槽均匀的分配给每个分片每个分片只需要记录自己拥有哪些槽位即可 详细的连接在上面Redis集群链接中 Redis集群会有操作丢失吗  Redis并不能保证数据的强一致性实际中集群在特定的条件下可能会丢失写操作 比如在成功写入一个key之后正好主节点宕机那么此时由于这个数据还未来得及同步到从节点也没来得及写入AOF日志就会丢失 如何理解Redis的事务和MySQL的事务有什么区别 区别 弱原子性不保证一致性不需要隔离性不需要持久化  Redis事务的本质就是在服务器搞了一个“事务队列”每次客户端进行操作的时候就先把命令保存在事务队列中收到EXEC命令后才会一起执行 Redis事务和MySQL事务的概念上是一样的都是把一系列的操作捆绑成一组让一组批量执行 什么是缓存穿透、缓存雪崩、缓存击穿  缓存穿透 访问的key不存在客户端也不存在服务端此时这样的key就不被缓存起来而高频的访问这个不存在的key就会导致Redis失去他“保护盾”的作用 解决办法: 1.布隆过滤器 2.将不存在的key也存在redis并随便设置value为. 3.对需要查询的key进行严格的合法性校验不合规的不让查 缓存雪崩 短时间内大量的key 在缓存上失效导致数据库压力暴增 解决方法 1.部署高可用的Redis集群 2.不给key设置时间或设置时间的时候添加随机时间因子 缓存击穿 相当于缓存血崩的特殊情况就是针对热点key过期了导致大量的请求访问到了MySQL上 解决方法 1.基于统计的方式发现热点key并设置永不过期 2.进行必要的服务降级访问数据的时候使用分布式锁限制并发数 Redis和MySQL如何保证双写一致性 什么是“双写一致性” 当用户修改数据的时候需要修改数据库同时也要更新缓存中的数据  如果直接写数据库并写Redis此时万一有一方写入失败就容易出现数据不一致情况 解决方法 方案一延迟双删 1.删除缓存数据 2.更新数据库 3.再删除缓存数据 方案二删除缓存重试 1.先删除缓存数据如果失败就把失败的key放到一个mq中稍后进行重试 Redis的“bigkey”问题 指的就是key对应的value很大占据较大的存储空间 可以使用redis-cli --bigkey查找bigkey删除bigkey尽量不要用del用unlink在后台删 这样的big可以会导致读写的时候性能下降如果是集群分配部署也会引起不同分片的数据倾斜 解决方案 核心思路就是拆分将大key拆成多个小key每个key对应value的一部分数据