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 查询的值是无序的
- (integer) 1
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条
- scan 0 match k1* count 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 的锁
- get locknx
如何解决 SETNX 长期有效的问题
- EXPIRE key seconds:存在风险
- 设置 key 的生存时间,当 key 过期时(生存时间为0),会被自动删除
- 代码实现:
- expire locknx 2
- (integer) 1
- 设置 locknx 锁过期时间为 2 秒钟
- expire 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)
- set locktarget 12345 ex 10 nx
大量的 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”
- rpush testlist aaa
缺点:没有等待队列里有值就直接消费
弥补:可以通过在应用层引入 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 文件,不阻塞服务器进程
- 父进程通过轮询的方式来接受子进程的消息
- SAVE:阻塞 Redis 的服务器进程,直到 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:将写入操作交给操作系统去决定
- 一般而言,操作系统会等待缓存区被填满才会开始同步数据到磁盘
- appendfsync always/everysec/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 的同步机制
全同步过程
- Slave 发送 sync 命令到 Master
- Master 启动一个后台进程,将 Redis 中数据快照保存到文件中
- Master 将保存数据快照期间接受到的写命令缓存起来
- Master 完成写文件操作后,将该文件(快照)发送给 Slave
- Slave 将接收到的文件保存到磁盘,然后加载到内存中恢复快照
- Slave 完成快照恢复后,Master 将这期间收集的增量写命令发送给 Slave端
- 后续读操作都是在 Slave 上,写操作都是在 Master 上
增量同步过程
- Master 接收到用户的操作指令,判断是否需要传播到 Slave
- 将操作记录追加到 AOF 文件
- 将操作传播到其他 Slave
- 对齐主从库
- 往响应缓存写入指令
- 将缓存中的数据发送给 Slave
主从同步的弊端
不具备高可用性,当 Master 挂掉之后,Redis 将不能对外提供写入操作(可用 Redis Sentinel 解决)
Redis Sentinel
解决主从同步 Master 宕机后的主从切换问题
主要功能
- 监控:检查主从服务器是否运行正常
- 提醒:通过 API 向管理员或者其他应用程序发送故障通知
- 自动故障迁移:主从切换
流言协议 Gossip
在杂乱无章中寻求一致
- 每个节点都随机地与对方通信,最终所有节点的状态达成一致
- 种子节点定时随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递给所有节点,但是最终会趋于一致