编程

Redis 常用知识点

勤劳的小蜜蜂 · 1月9日 · 2020年

redis 简介

缓存中间件 — Memcache和Redis的区别

Memcache:代码层类似Hash

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

Redis

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

为什么Redis能这么快:100000+QPS (QPS即query per second,每秒内查询次数)

  • 完全基于内存,绝大部分请求是纯粹的内存操作,执行效率高
    • redis采用的是单进程、单线程模型的KV数据库,由C语言编写,它将数据存在内存里面,读写数据的时候都不会受到硬盘IO速度的限制
  • 数据结构简单,对数据操作也简单
  • 采用单线程,单线程也能处理高并发请求,想多核也可启动多实例
    • 因为是单线程,所以多个客户端对一个键进行操作的时候,不会有并发问题,避免了频繁的上下文切换和锁竞争
    • 并发不是并行
    • cpu不是制约redis的性能瓶颈,会受网络的影响
  • 使用多路I/O服用模型,非阻塞I/O

redis 数据类型

String:最基本的数据类型,二进制安全

  • set name “redis”
  • get name
  • set 已经存在的数据,之前的数据会被覆盖
  • set count 1
  • get count
  • incr count // (integer) 2
  • get count // “2”
  • String的安全性基于底层字符串 sdshdr

Hash:String元素组成的字典,适合用于存储对象

  • hmset lilei name “Lilei” age 26 title “Senior”
    • 创建一个名为 lilei 的映射表
  • hget lilei age
    • “26”
    • 获取映射表中的字段值
  • hset lilei title “Pricipal”
    • 修改 lilei 映射表中的字段

List:列表,按照 String 元素插入顺序排序

  • 数据是后进先出(类似于栈)
  • 适合实现最新消息等功能
  • lpush
    • 从左往右添加元素
  • rpush
    • 从右到左添加元素
  • lpush mylist aaa
    • (integer) 1
    • 返回列表中数据的个数
  • lrange mylist 0 10
    • 从第0位取出10个

Set:String 元素组成的无序集合,通过哈希表实现,不允许重复

  • 值不允许重复
  • 添加、删除、查找的时间复杂度都是O(1)
  • 适合存储集合性数据,比如微博中用户所有的关注人存在一个集合中、所有粉丝存在一个集合,因为 redis 提供求交集、求并集、求差集等操作,如此很容易实现共同喜好、共同关注等功能
  • sadd myset 111
    • (integer) 1
      • 返回的结果 1 代表成功,0 代表失败
    • smembers myset
      • 1) “111”
      • smembers 查询的值是无序

Sorted Set:通过分数来为集合中的成员进行从小到大的排序

  • 分数可以重复,值不允许重复
  • zadd myzset 3 abc
    • 3为分数,abc为值
  • zrangebyscore myzset 0 10
    • 分数越小,排序越靠前

用于计数的 HyperLogLog

用于支持存储地理位置信息的 Geo

redis 底层数据类型基础

  • 简单动态字符串
  • 链表
  • 字典
  • 跳跃表
  • 整数集合
  • 压缩列表
  • 对象

redis的单个操作都是原子性的,所以不用考虑并发

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

使用 keys 对线上的业务的影响

  • KEYS pattern:查找所有符合给定模式 pattern 的 key
    • KEYS 指令一次性返回所有匹配的 key
    • 键的数量过大会使服务卡顿

SCAN cursor [MATCH pattern] [COUNT count]

  • 无阻塞的提取出指定模式的 key 列表
  • 每次执行只会返回少量元素,所以可以用于生产环境
  • 基于游标的迭代器,需要基于上一次的游标延续之前的迭代过程
  • 以0作为游标开始一次新的迭代,直到命令返回游标0完成一次遍历
    • 从0到0为一次完成的遍历
  • 不保证每次执行都返回某个给定数量的元素,支持模糊查询
  • scan 因为是分批量的查询,所以花费的时间要比 keys 要长
  • 一次返回的数量不可控,只能是大概率符合 count 参数
  • 用法
    • scan 0 match k1* count 10
      • 查询以 k1 开头的数据,每次大约10条

返回的第一个数据是游标的位置,第二次返回的游标数比第三次大,是因为有重复的值,可以通过将查询的数据放入到 Set 中来达到去重的目的

如何通过 Redis 实现分布式锁

分布式锁:控制分布式系统或不同系统之间访问共享资源锁的实现

分布式锁需要解决的问题

  • 互斥性
    • 任意时刻只能有一个客户端获取锁,不能同时有两个客户端获取到锁
  • 安全性
    • 锁只能被持有的客户端删除,不能由其它客户端删除
  • 死锁
    • 获取锁的客户端因为某些原因而宕机,未能释放锁,其它客户端再也没法获取到该锁,而导致了死锁
  • 容错
    • 某个节点宕机之后,客户端任然能获得锁、释放锁

SETNX key value:如果 key 不存在,则创建并赋值;如果 key 存在,则设置失败

  • 执行某段代码逻辑的时候,先尝试使用 setnx 对某个 key 设值,如果设值成功,则证明此时没有别的线程在执行该段代码;如果设置失败,则证明有别的程序或者线程占用该资源,那么当前线程就要等待,直至 setnx 成功
  • 时间复杂度:O(1)
  • 返回值:设置成功,返回1;设置失败,返回0
  • 代码实现:
    • get locknx
      • (nil)
      • 获取名为 locknx 的锁,返回 nil 则该锁不存在
    • setnx locknx test
      • (integer) 1
      • 设置名为 locknx,值为 test 的锁

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

  • EXPIRE key seconds:存在风险
    • 设置 key 的生存时间,当 key 过期时(生存时间为0),会被自动删除
    • 代码实现:
      • expire locknx 2
        • (integer) 1
        • 设置 locknx 锁过期时间为 2 秒钟

可以解决问题,但是存在风险,若程序未执行到 expire 挂掉,就永远死锁了

原因:原子性得不到满足,虽然 setnx 和 expire 都是原子性的操作,但是组合在一起就不是了

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

  • EX seconds:设置键的过期时间为 second 秒
  • PX milliseconds:设置键的过期时间为 millisecond 毫秒
  • NX:只在键不存在时,才对键进行设置操作
  • XX:只在键已经存在时,才对键进行设置操作
  • SET操作成功完成时,返回 OK,否则返回 nil
  • 代码实现:
    • set locktarget 12345 ex 10 nx
      • OK
    • set locktarget 123456 ex 10 nx
      • (nil)

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

  • 集中过期,由于清楚大量的 key 很耗时,会出现短暂的卡顿现象
    • 解决方案:在设置 key 的过期时间的时候,加上随机值

如何使用 Redis 做异步队列

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

  • 代码实现:
    • rpush testlist aaa
      • (integer) 1
    • rpush testlist bbb
      • (integer) 2
    • rpush testlist ccc
      • (integer) 3
    • lpop testlist
      • “aaa”
    • lpop testlist
      • “bbb”
    • lpop testlist
      • “ccc”

缺点:没有等待队列里有值就直接消费

弥补:可以通过在应用层引入 Sleep 机制去调用 LPOP 重试

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

  • timeout 单位为秒
  • 缺点:只能供一个消费者消费

pub/sub:主题订阅者模式

  • 发送者(pub)发送消息,订阅者(sub)接收消息
  • 订阅者可以订阅任意数量的频道
  • 订阅频道:subscribe key
  • 发布消息:publish key value

缺点:消息的发布是无状态的,无法保证可达,使用专业的消息队列可以解决,如卡夫卡

持久化方式之 RDB

RDB(快照)持久化:保持某个时间点的全量数据快照

redis.conf 配置

  • save 900 1
    • 900 秒之内有 1 次写入指令,就产生一次快照
  • stop – writes – on – bgsave – error yes
    • 当备份进程出错的时候,主进程就停止接受新的写入操作
    • 目的是为了保护持久化数据的一致性问题
  • rdbcompression no
    • 在备份的时候需要将 rdb 文件压缩后保存
    • 建议设置为 no,因为 redis 是 cpu 密集型服务器,再开启压缩会带来更多的 cpu 消耗
  • 禁用 rdb 配置
    • save “”

RDB 文件保存在 src 目录下 dump.rdb

RDB 的创建与载入

  • RDB 文件可以通过两个命令生成
    • SAVE:阻塞 Redis 的服务器进程,直到 RDB 文件被创建完毕
      • 很少被使用,因为 Redis 是只用一个主线程来处理请求,这种方式会阻塞所有 Client 的请求
    • BGSAVE:Fork 出一个子进程来创建 RDB 文件,不阻塞服务器进程
      • 父进程通过轮询的方式来接受子进程的消息
  • LASTSAVE:
    • 查询 save 或 bgsave 是否成功,返回成功的时间戳

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

  • 根据 redis.conf 配置里的 SAVE m n 定时触发(用的是 BGSAVE)
  • 主从复制时,主节点自动触发
  • 执行 Debug Reload
  • 执行 Shutdown 且没有开启 AOF 持久化

缺点

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

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

AOF(Append-Only-File)持久化:保存写状态

AOF 持久化默认是关闭

  • 生效方式:
    • 打开 redis.conf
    • 修改 appendonly no 为 appendonly yes
      • 或者在连接 redis 的命令行下开启:config set appendonly yes
  • AOF 文件写入方式配置:
    • appendfsync always/everysec/no
      • always:一旦缓存区的内容变化,总是及时的将缓存区的内容写到 AOF 中
      • everysec(默认方式 && 推荐):将缓存区的内容每隔一秒写到 AOF 的文件中
      • no:将写入操作交给操作系统去决定
        • 一般而言,操作系统会等待缓存区被填满才会开始同步数据到磁盘

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

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

手动调用 aof 重写命令:bgrewriteaof

RDB 和 AOF 文件共存情况下的恢复流程

AOF 与 RDB 不同点

  • RDB:备份数据库状态
  • AOF:备份数据库接收到的写命令

RDB 和 AOF 的优缺点

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

RDB – AOF 混合持久化方式(Redis 4.0 之后 && 默认配置)

BGSAVE 做镜像全量持久化,AOF 做增量持久化

Pipeline 及主从同步

使用 Pipeline 的好处

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

Redis 的同步机制

全同步过程

  1. Slave 发送 sync 命令到 Master
  2. Master 启动一个后台进程,将 Redis 中数据快照保存到文件中
  3. Master 将保存数据快照期间接受到的写命令缓存起来
  4. Master 完成写文件操作后,将该文件(快照)发送给 Slave
  5. Slave 将接收到的文件保存到磁盘,然后加载到内存中恢复快照
  6. Slave 完成快照恢复后,Master 将这期间收集的增量写命令发送给 Slave端
  7. 后续读操作都是在 Slave 上,写操作都是在 Master 上

增量同步过程

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

主从同步的弊端

不具备高可用性,当 Master 挂掉之后,Redis 将不能对外提供写入操作(可用 Redis Sentinel 解决)

Redis Sentinel

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

主要功能

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

流言协议 Gossip

在杂乱无章中寻求一致

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