使用 Redis 作缓存、分布式锁、持久化、主从、集群

lmmarisej
192 阅读7分钟

本文已参与「新人创作礼」活动，一起开启掘金创作之路。

主流缓存架构

image.png

发起数据获取请求时先从缓存中查询，再从数据库查询，能有效降低数据库访问问压力。

缓存中间件选型

—— Memcache 和 Redis 的区别。

Memcache

代码层次类似 Hash：

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

Redis

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

可以看出 Redis 具有更多功能，不过在项目落地中主要还是根据自己的业务进行技术选型。

Redis 介绍

Redis 能成为主流的缓存中间件其中不乏一些优秀的思想与强大的功能支持，我们对 Memcache 就不再展开，下面主要对 Redis 进行一个介绍。

为什么 Redis 能这么快

10w+ QPS （QPS即query per second，每秒内查询次数）

  • 完全基于内存，大多数请求纯内存操作。
  • 数据结构简单，操作简单。
  • 单线程处理高并发，多核可以多实例。
  • 采用多个I/O复用模式，无阻塞IO。

Redis 采用的 I/O 多路复用函数

epoll/kqueue/evport/select？

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

Redis 的数据类型

供用户使用的数据类型

  • String：最基本的数据类型，二进制安全。 
     struct sdshdr { // 保存字符串对象的结构
     int len;    // buf 中己占用空间的长度 
     int free;   // buf 中剩余可用空间的长度 
     char bufn;  // 数据空间
 }；
  • Hash: String 元素组成的字典，存储对象。
  • List：列表，String 元素插入顺序排序。
  • Set：String 元素组成的无序集合，哈希表实现，不允许重复。
  • Sorted Set：以分数为集合中的成员进行从小到大的排序。
  • 计数 HyperLogLog。
  • 存储地理位置信息 Geo。

Redis 底层数据类型基础

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

Redis 从海量 Key 里查询出某一固定前缀的 Key

摸清数据规模，即问清楚边界

方法一：KEYS pattern

查找所有符合给定模式 pattern 的 key。

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

方法二：SCAN cursor [MATCH pattern] [COUNT count]

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

Redis 实现分布式锁

分布式锁需要解决的问题

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

1.SETNX key value

如果 key 不存在，则创建并赋值

  • 时间复杂度：0（1）
  • 返回值：设置成功，返回1；设置失败，返回0。

2.如何解决 SETNX 长期有效的问题

EXPIRE key seconds：设置key的生存时间，当key过期时(生存时间为0），会被自动删除。

缺点：原子性得不到满足。

3.如何解决 SETNX 原子性的问题

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

  • EX second：设置键的过期时间为 second 秒
  • PX millisecond：设置键的过期时间为 millisecond 毫秒
  • NX：只在键不存在时，才对键进行设置操作
  • XX：只在键已经存在时，才对键进行设置操作
  • SET 操作成功完成时，返回 OK，否则返回 nil

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

集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象。

解放方案：在设置key的过期时间的时候，给每个key加上随机值。

Redis 做异步队列

使用 List 作为队列，RPUSH 生产消息，LPOP 消费消息。

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

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

缺点：只能供一个消费者消费。

多消费者

pub/sub：主题订阅者模式。

  • 发送者(pub)发送消息，订阅者(sub)接收消息。
  • 订阅者可以订阅任意数量的频道。

pub/sub的缺点：消息的发布是无状态的，无法保证可达。

Redis 持久化

RDB(快照）持久化

保存某个时间点的全量数据快照。

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

自动化触发 RDB 持久化的方式：

  • redis.conf 配置 SAVE m n 定时触发（BGSAVE）。
  • 主从复制时，主节点自动触发。
  • 执行 Debug Reload。
  • 执行 Shutdown 且没有开启 AOF 持久化。

持久化的触发会首先检查是否存在子进程正在持久化，没有则进行持久化。

系统调用fork()：创建进程，实现了Copy-on-Write。

copy-on-Write：如果有多个调用者同时要求相同资源（如内存或磁盘上的数据存储)，他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。

缺点：

  • 内存数据的全量同步，数据量大会由于 I/O 而严重影响性能。
  • 可能会因为 Redis 挂掉而丢失从当前至最近一次快照期间的数据。

AOF（Append-Only-File）持久化

保存写状态。

  • 记录下除了查询以外的所有变更数据库状态的指令。
  • append 增量追加保存到 AOF 文件。

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

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

Redis 数据的恢复

优先使用 AOF，AOF 不存在再使用 RDB。

RDB 和 AOF 的优缺点

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

RDB-AOF混合持久化方式

BGSAVE镜像全量，AOF增量。

Pipeline

Redis基于请求/响应模型，单个请求处理需要一一应答，Pipeline批量执行指令，节省多次 IO 往返的时间。

有顺序依赖的指令建议分批发送。

Redis 同步

全同步

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

增量同步

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

Redis Sentinel

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

  • 监控：检查主从是否运行正常
  • 提醒：通过 API 发送故障通知
  • 自动故障迁移：主从切换

Redis 集群

海量数据存储：分片，按照某种规则去划分数据，分散存储在多个节点上。缺点，常规的按照哈希划分无法实现节点的动态增减。

使用一致性哈希算法：对 2^32 取模，将哈希值空间组织成虚拟的圆环，将数据 key 使用相同的函数 Hash 计算出哈希值。

avatar
文章
阅读
粉丝