• 4-1 Redis简介
• 4-2 Redis常用数据类型
• 4-3 从海量数据里查询某一固定前缀的key
• 4-4 如何实现分布式锁
• 4-5 如何实现异步队列
• 4-6 持久化方式之RDB
• 4-7 持久化方式之AOF以及混合模式
• 4-8 Pipeline及主从同步
• 4-9 Redis集群

4-1 Redis简介

• 主流应用架构
  
• 缓存中间件——Memcache 和 Redis 的区别
  • Memcache：代码层类似Hash
    • 支持简单数据类型
    • 不支持数据持久化存储
    • 不支持主从
    • 不支持分片(Sharding)
  • Redis
    • 数据类型丰富
    • 支持数据瓷盘持久化存储
    • 支持主从
    • 支持分片
• 为什么 Redis 能这么快(100000+QPS(QPS即 query per second，每秒查询次数))
  • 完全基于内存，绝大部分请求是纯粹的内存操作 ，执行效率高
  • 数据结构简单，对数据操作也简单
  • 采用单线程，单线程也能处理高并发请求，想多核也可以启动多实例
  • 使用多路 I/O 复用模型，非阻塞 IO
• 多路 I/O 复用模型——Redis 采用的 I/O 多路复用函数：epoll/kqueue/evport/select
  • 因地制宜
  • 优先选择时间复杂度为 O(1) 的 I/O 多路复用函数作为底层实现
  • 以时间复杂度为 O(n) 的 select 作为保底
  • 基于 react 设计模式监听 I/O 事件

4-2 Redis常用数据类型

• String：最基本的数据类型，二进制安全

  /**
   * 保存字符串对象的结构
   */
  struct sdshdr {
      //buf 中已占用的空间长度
      int len;
      //buf 中剩余可用的空间长度
      int free;
      //数据空间
      char bur[];
  };
  

• Hash：String 元素组成的字典，适用于存储对象
• List：列表，按照 String 元素插入顺序排序
• Set：String 元素组成的无序集合，通过哈希表实现，不允许重复
• Sorted Set：通过分数来为集合中的成员进行从小到大的排序
• 用于计数的 HyperLogLog，用于支持存储地理位置信息的 Geo

4-3 从海量数据里查询某一固定前缀的key

• 【细节】摸清数据规模，即问清楚边界
• KEYS pattern：查找所有符合给定模式 pattern 的 key
  • KEYS 指令一次性返回所有匹配的 key
  • 键的数据过大会使服务卡顿
• SCAN cursor [MATCH pattern][COUNT count]
  
  • 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
  • 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
  • 不保证每次执行都返回某个给定数量的元素，支持模糊查询
  • 一次返回的数量不可控，只能是大概率符合 count 参数

4-4 如何实现分布式锁

• 分布式锁需要解决的问题
  • 互斥性
  • 安全性
  • 死锁
  • 容错
• SETNX key value：如果 key 不存在，则创建并赋值
  • 时间复杂度：O(1)
  • 返回值：设置成功，返回1；设置失败，返回0。
• 如何解决SETNX长期有效的问题
  • 设置 key 的生存时间，当 key 过期时（生存时间为0），会被自动删除（EXPIRE key seconds）
• SET key value [EX seconds][PX milliseconds][NX|XX]
  • EX seconds：设置键的过期时间为 second 秒
  • PX milliseconds：设置键的过期时间为 millisecond 毫秒
  • NX：只在键不存在时，才对键进行设置操作
  • XX；只在键已经存在时，才对键进行设置操作
  • SET 操作成功完成时，返回 OK，否则返回 nil
• 大量 key 集中过期，由于清除大量 key 很耗时，会出现短暂的卡顿现象
  • 解决方案：在设置 key 的过期时间的时候，给每个 key 加上随机值

4-5 如何实现异步队列

• 使用 List 作为队列，RPUSH 生产消息，LPOP 消费消息
  • 缺点：没有等待队列里有值就直接消费
  • 弥补：可以通过在应用层引入 Sleep 机制去调用 LPOP 重试
• BLPOP key [key...] timeout：阻塞直到队列有消息或者超时
  • 缺点：只能供一个消费者消费
• pub/sub：主题订阅者模式
  • 发送者(pub)发送消息，订阅者(sub)接收消息
  • 订阅者可以订阅任意数量的频道
  • 缺点：消息的发布时无状态的，无法保证可达

4-6 持久化方式之RDB

• RDB持久化-保存某个时间点的全量数据快照
  • 手动触发
    • SAVE：阻塞 Redis 的服务器进程，直到 RDB 文件被创建完毕
    • BGSAVE：Fork 出一个子进程来创建 RDB 文件，不阻塞服务器进程
  • 自动化触发
    • 根据 redis.conf 配置里的 SAVE m n 定时触发（用的是 BGSAVE）
    • 主存复制时，主节点自动触发
    • 执行 Debug Reload
    • 执行 Shutdown 且没有开启 AOF 持久化
• 缺点
  • 内存数据的全量同步，数据量打会由于 I/O 严重影响性能
  • 可能会因为 Redis 挂掉而丢失从当前至最近一次快照期间的数据

4-7 持久化方式之AOF以及混合模式

• AOF(Append-Only-File) 持久化：保存写状态
  • 记录下除了查询以外的所有变更数据库状态的指令
  • 以 append 的形式追加保存到 AOF 文件中（增量）
• 日志重写解决 AOF 文件大小不断增大的问题，原理如下：
  • 调用 fork()，创建一个子进程
  • 子进程把新的 AOF 写到一个临时文件里，不依赖原来的 AOF 文件
  • 主进程持续将新的变动同时写到内存和原来的 AOF 里
  • 主进程获取子进程重写 AOF 的完成信号，往新 AOF 同步增量变动
  • 使用新的 AOF 文件替换掉旧的 AOF 文件
• Redis在 RDB 和 AOF 文件共存的情况下的恢复流程
  
• RDB 和 AOF 的优缺点
  • RDB
    • 优点：全量数据快照，文件小，恢复快
    • 缺点：无法保存最近一次快照之后的数据
  • AOF
    • 优点：可读性高，适合保存增量数据，数据不易丢失
    • 缺点：文件体积大，恢复时间长
• RDB-AOF 混合持久化方式
  • BGSAVE 做镜像全量持久化，AOF 做增量持久化

4-8 Pipeline及主从同步

• 使用 Pipeline 的好处
  Pipeline 类似于 Linux 的管道类似

  • Redis 基于请求/响应模型，单个请求处理需要一一应答
  • Pipeline 批量执行指令，节省多次 I/O 往返的时间
  • 有顺序依赖的指令建议分批发送

• Redis 的同步机制

  • 主从同步：一般集群都是一个主多个从，主负责写，从负责读。开始主节点会启动命令开始全量同步，然后会启动增量同步。

    • 全同步过程：
      • Slave发送sync命令到Master
      • Master启动一个后台进程，将Redis中的数据快照保存到文件中（bgsave）
      • Master将保存的数据快照期间接收到的写命令也缓存起来（增量数据缓存）
      • Master完成写操作之后，将该文件发送给Slave
      • 使用新的AOF文件替换掉旧的AOF文件，然后写入内存中，恢复数据快照
      • Master将这期间收集的增量写命令也发送给Slave，Slave完成同步
    • 增量同步过程：
      • Master接收到用户的操作指令，判断是否需要传播到Slave
      • 将操作记录追加到AOF文件
      • 将该操作传播到其他Slave ,对齐住从库，往响应的缓存写入指令
      • 将缓存中的数据发送给Slave
      • 主从的弊端就是主服务器挂掉之后就不能进行写操作了，所以就有了sentinel 哨兵

  • Redis Sentinel：解决主从同步Master宕机后的主从切换问题：

    • 监控：检查主从服务器是否运行正常
    • 提醒：通过API向管理员或者其他应用程序发送故障通知
    • 自动故障迁移：主从切换

• 流言协议Gossip，在杂乱无章中寻求一致（区块链中有用到）：

  • 每个节点都随机地与对方通信，最终所有节点的状态达成一致
  • 种子节点定期随机向其他节点发送节点列表以及传播的消息
  • 不保证信息一定会传播给所有节点，但是最终会趋于一致

4-9 Redis集群

• 如何从海量数据里快速找到所需？
  • 分片：按照某种规则去划分数据，分散存储在多个节点上
  • 常规的按照哈西划分无法实现节点的动态增减