🐽详细讲解主流缓存面试会遇到的问题，包含Redis分布式锁、异步队列、持久化、集群等🐽

主流缓存Redis笔记

1. 主流应用架构

1.1 缓存中间件---- Memcache和Redis的区别

1. Memcache：代码层次类似Hash

  • 支持简单数据类型
  • 不支持数据持久化存储
  • 不支持主从
  • 不支持分片

2. Redis

  • 数据类型丰富
  • 支持数据磁盘持久化存储
  • 支持主从
  • 支持分片

1.2 为什么Redis能这么快

1. 100000+QPS（每秒内查询次数）

  • 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
  • 数据结构简单，对数据操作也简单
  • 采用单线程，单线程也能处理高并发请求，想多核也可以启动多实例
  • 使用多路I/O复用模型，非阻塞IO

1.3 多路I/O复用模型

1. FD: File descriptor，文件描述符

  • 一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射

2. 传统的阻塞I/O模型

3. Select 系统调用

4. Redis采用的I/O多路复用函数：epoll/kqueue/evport/select

  • 因地制宜
  • 优先学则时间复杂度为O(1)的I/O多路复用函数作为底层实现
  • 以时间复杂度的O(N)的select作为保底
  • 基于react设计模式监听I/O事件

2. Redis的数据类型

1. 供用户使用的数据类型

  • String：最基本的数据类型，二进制安全（底层使用sdshdr）

  • Hash：String元素组成的字典，适合用于存储对象（hmset key1 value1 key2 value2...）

  • List：列表，按照String元素插入顺序排序

  • Set：String元素组成的无序集合，通过哈希表实现，不允许重复(sadd myset 1)

  • Sorted Set：通过分数来为集合中的成员进行从小到达的排序（zadd myzset 3 a)\

  • 高级：用来计数的HyperLogLog，用于支持存储地理位置信息的Geo

2. 底层数据类型基础

  1. 简单动态字符串
  2. 链表
  3. 字典
  4. 跳跃表
  5. 整数集合
  6. 压缩列表
  7. 对象

3. 从海量key里查询某一固定前缀的Key

1. KEYS pattern：查找所有符合给定模式pattern的key

  • KEYS指令一次性返回所有匹配的key
  • 键的数量过大会使得服务卡顿

2. SCAN cursor [MATCH pattern] [COUNT count]

  • 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
  • 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
  • 不保证每次执行都返回某个给定数量的元素，支持模糊查询
  • 一次返回的数量不可控，只能是大概率符合count参数

4. 如何通过Redis实现分布式锁

1. 分布式锁需要解决的问题

  • 互斥性
  • 安全性
  • 死锁
  • 容错

2. SETNX key value：如果key不存在，则创建并赋值

3. 解决SETNX 长期有效的问题

  1. EXPIRE key seconds

    • 设置key的生存时间，当key过期时（生存时间为0），会被自动删除

  3. SET key value [EX seconds] [PX milliseconds] [NX|XX]

    • EX second：设置键的过期时间为second秒
    • PX millisecond：设置键的过期时间为millisecond毫秒
    • NX ：只在键不存在时候，才对键进行操作 （等同于上面 SETNX key value）
    • XX：只在键不存在时候，才对键进行操作
    • SET 操作成功完成时， 返回OK, 否则返回nil

4. 大量key同时过期的注意事项

  1. 集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象
  2. 解决方案：在设置key的过期时间的时候，给每个key加上随机值

5. 使用Redis做异步队列

1. 使用List作为队列

  1. RPUSH生产消息 LPOP消费消息

    • 缺点：没有等待队列里有值就直接消费
    • 可以通过在应用层引入Sleep机制去调用LPOP重试

  2. BLPOP key [key...] timeout：阻塞直到队列有消息或者超时

2. pub/sub：主题订阅者模式

  • 发送者（pub）发送消息，订阅者（sub）接收消息
  • 先订阅一个频道，会自动获得这个频道里的消息
  • 缺点：消息的发布是无状态的，无法表征可达

6. Redis如何做持久化

1. RDB（快照）持久化：保存某个时间点的全量数据快照

  1. SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
  2. BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器

2. 自动化触发RBD持久化的方式

  1. 根据redis.conf配置里的SAVE m n 定时触发（用的是BGSAVE）
  2. 主从复制时，主节点自动触发
  3. 指定Debug Reload
  4. 执行Shutdown且没有开发AOF持久化

3. BGSAVE的原理

  • 系统调用fork()：创建进程，实现了Copy-on-Write
  • 缺点
    • 内存数据的全量同步，数据量大会由于I/O而影响性能
    • 可能会因为Redis挂掉而损失从当前至最近一次快照期间的数据

4. AOF（Append-Only-File）持久化：保存写状态

  1. 记录下除了查询以外的所有变更数据库状态的指令

  2. 以append的形式追加保存到AOF文件中（增量）

  3. AOF默认是关闭的 在conf文件中配置

  4. 日志重写解决AOF文件大小不断增大的问题，原理如下：

    • 调用fork（），创建一个子进程
    • 子进程吧新的AOF写到一个临时文件里，不依赖原来的AOF文件
    • 主进程持续将新的变动同时写到内存和原来的AOF里
    • 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
    • 使用新的AOF文件替换掉旧的AOF文件

5. 数据恢复过程

  1. 先看有没有AOF文件，再恢复
  2. 在看有没有RDB文件，再恢复

6. 两者优缺点

  1. RDB优点：全局数据快照，文件小，恢复快
  2. RDB缺点：无法保存最近一次快照之后的数据
  3. AOF优点：可读性高，适合保存增量数据，数据不易丢失
  4. AOF缺点：文件体积大，恢复时间长

7. 使用RDB-AOF混合持久化方式

  • BGSAVE做镜像全量持久化，AOF做增量持久化

7. Pipeline

1. 使用pipeline的好处

  1. pipeline和linux的管道类似
  2. redis基于请求/相应模型，单个请求处理需要一一应答
  3. Pipeline批量执行指令，节省多次IO往返的时间
  4. 有顺序依赖的指令建议分批发送

2. Redis的同步机制

  1. 主从同步原理（Master/Slave）

  2. 全同步过程

    • Slave发送sync命令到master
    • Master启动一个后台进程，将Redis中的数据快照保存到文件中（BGSAVE）
    • Master将保存数据快照期间接收到的写命令缓存起来
    • Master完成写文件操作后，将该文件发送给Slave
    • 使用新的AOF文件替换掉旧的AOF文件
    • Master将这期间收集到的增量写命令发送给Slave端

  3. 增量同步过程

    • Master接收到用户的操作指令，判断是否需要传播到Slave
    • 将操作记录追加到AOF文件
    • 将操作传播到其他Slave：
      1. 对齐主从库
      2. 往相应缓存写入指令
    • 将缓存中的数据发送给Slave

  4. Redis Sentinel（Redis哨兵）

    1. 解决主从同步Master宕机后的主从切换问题：
      • 监控：检查主从服务器是否运行正常
      • 提醒：通过API向管理员或者其他应用程序发送故障通知
      • 自动故障迁移：主从切换

  5. 流言协议Gossip

    1. 在杂乱无章中寻求一致
    2. 每个节点都随机地与对方通信，最终所有节点的状态达成一致
    3. 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
    4. 不保证信息一定会传递给所有节点，但是最终会趋于一致

8. Redis集群

1. 如何从海量数据里快速找到所需

  • 分片：按照某种规则去划分数据，分散存储在多个节点上

2. Redis的集群原理

  • 一致性哈希算法：对 2^32 取模，将哈希值空间组织成虚拟的圆环

  • 将数据key使用相同的函数Hash计算出哈希值，找到最近的Hash节点

  • 如果此时Node C宕机,数据都会到Node D中

  • 新增一台服务器 Node X

3. 数据倾斜问题

  1. Hash环的数据倾斜问题

  2. 引入虚拟节点解决数据倾斜的问题（节点过少时有用）（设置虚拟节点32个）