仅作为面试知识点记录,具体课程请在慕课网搜索剑指Java面试-Offer直通车
文章目录
缓存
主流应用架构
缓存中间件——Memcache和Redis的区别
Memcache:代码层类似Hash
- 支持简单数据类型
- 不支持数据持久化存储
- 不支持主从
- 不支持分片
Redis
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
为什么Redis能这么快
100000+QPS(QPS即query per second, 每秒内查询速度)
- 完全基于内存,绝大部分请求是纯粹的内存操作,执行效率很高
- 数据结构简单,对数据操作也简单
- 采用单线程,单线程也能处理高并发请求,向多核也可启动多实例
- 使用多路I/O复用模型,非阻塞IO
多路I/O复用模型
FD:File Descriptor,文件描述符
一个打开的文件通过唯一的描述符进行引用,该描述符是打开文件的元数据到文件本身的映射
传统的阻塞I/O模型
Select系统调用
Redis采用的I/O多路复用函数:epoll/kqueue/evport/select?
- 因使用环境来决定
- 优先选择时间复杂度为O(1)的多路复用函数作为底层实现
- 以时间复杂度为O(n)的select作为保底
- 基于react设计模式监听I/O事件
Redis的数据类型
- String:最基本的数据类型,二进制安全
- Hash:String元素组成的字典,适合用于存储对象
- List:列表,按照String元素插入顺序排序
- Set:String元素组成的无序集合,通过哈希表实现,不允许重复
- Sorted Set:通过分数来为集合中的成员进行从小到大的排序
- 用于计数的HyperLogLog,用于支持存储地理位置的Geo
使用keys对线上的业务的影响
KEYS pattern:查找所有符合给定模式pattern的key
- KEYS指令一次性返回所有匹配的key
- 键的数量过大会使服务卡顿
从海量Key里查询出某一固定前缀的Key
SCAN cursor [MATCH pattern] [COUNT count]
- 基于游标的迭代器,需要基于上一次的游标延续之前的迭代过程
- 以0作为游标开始一次新的迭代,知道命令返回游标0完成一次遍历
- 不保证每次执行都返回某个给定数量的元素,支持模糊查询
- 一次返回的数量不可控,只能是大概率符合count参数
如何通过Redis实现分布式锁
分布式所需要解决的问题
- 互斥性
- 安全性
- 死锁
- 容错
SETNX key value:如果key不存在,则创建并赋值
- 时间复杂度:O(1)
- 返回值:设置成功,返回1;设置失败,返回0
如何解决SETNX长期有效的问题
EXPIRE key seconds
- 设置key的生存时间,当key过期时(生存时间为0),会被自动删除
- 缺点:原子性得不到满足
SET key value [EX seconds] [PX milliseconds] [NX|XX]*
- EX seconds:设置键的过期时间为second秒
- PX millisecond:设置键的过期时间为millsecond毫秒
- NX:只在键不存在时,才对键进行设置操作
- XX:只在键已经存在时,才对键进行设置操作
- SET操作成功完成时,返回OK,否则返回nil
大量key同时过期时的注意事项
集中过期,由于清除大量的key很耗时,会出现短暂的卡顿现象
- 解决方案:在设置key的过期时间的时候,给每个key加上随机值
如何使用Redis做异步队列
使用List作为队列,RPUSH生产消息,LPOP消费消息
- 缺点:没有等待队列里有值就直接消费
- 弥补:可以通过在应用层引入Sleep机制去调用LPOP重试
BLPOP key [key …] timeout:阻塞直到队列有消息或者超时
- 缺点:只能供一个消费者消费
pub/sub:主题订阅者模式
- 缺点:消息的发布是无状态的,无法保证可达
Redis如何做持久化
RDB(快照)持久化:保存某个时间点的全量数据快照
- SAVE:阻塞Redis的服务器进程,直到RDB文件被创建完毕
- BGSAVE:Fork出一个子进程来创建RDB文件,不阻塞服务器进程
自动化触发RDB持久化的方式
- 根据redis.conf配置里的SAVE m n 定时触发(用的是BGSAVE)
- 主从复制时,主节点自动触发
- 执行Debug Reload
- 执行Shutdown且没有开启AOF持久化
BGSAVE原理
- 系统调用fork():创建进程,实现了Copy-on-Write
Copy-on-Write
RDB持久化缺点
- 内存数据的全量同步,数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
AOF(Append-Only-File)持久化:保存写状态
- 记录下除了查询以外的所有变更数据库状态的指令
- 以append的形式追加保存到AOF文件中(增量)
日志重写解决AOF文件大小不断增大的问题,原理如下
- 调用fork(),创建一个子进程
- 子进程把新的AOF写到一个临时文件里,不依赖原来的AOF文件
- 主进程持续将新的变动同时写到内存和原来的AOF里
- 主进程获取子进程重写AOF的完成信号,往新AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
Redis数据的恢复
RDB和AOF文件共存情况下的恢复流程
RDB和AOF的优缺点
- RDB优点:全量数据快照,文件小,恢复快
- RDB缺点:无法保存最近一次快照之后的数据
- AOF优点:可读性高,适合保存增量数据,数据不易丢失
- AOF缺点:文件体积大,恢复时间长
RDB-AOF混合持久化方式
- BGSAVE做镜像全量持久化,AOF做增量持久化
Pipeline的好处
- Pipeline和Linux的管道类似
- Redis基于请求/响应模型,单个请求处理需要一一应答
- Pipeline批量执行指令,节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
Redis的同步机制
主从原理
全同步过程
- Slave发送sync命令到Master
- Master启动一个后台进程,将Redis中的数据快照保存到文件中
- Master将保存数据快照期间接收到的写命令缓存起来
- Master将保存数据快照期间接收到的写命令缓存起来
- Master完成写文件操作后,将该文件发送给Slave
- 使用新的AOF文件替换掉旧的AOF文件
- Master将这期间收集的增量写命令发送给Slave端
增量同步过程
- Master接收到用户的操作指令,判断是否需要传播到Slave
- 将操作记录追加到AOF文件
- 将操作传播到其他Slave:1.对齐主从库;2.往响应缓存写入指令
- 将缓存中的数据发送给Slave
Redis Sentinel
解决主从同步Master宕机后的主从切换问题
- 监控:检查主从服务器是否运行正常
- 提醒:通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移:主从切换
流言协议Gossip
在杂乱无章中寻求一致
- 每个节点都随机地与对方通信,最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递给所有节点,但是最终会趋于一致
Redis的集群原理
如何从海量数据里快速找到所需
- 分片:按照某种规则去划分数据,分散存储在多个节点上
- 常规的按照哈希划分无法实现节点的动态增减