Redis

一、Redis简介

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

Memcache：代码层次类似Hash

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

Redis

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

为什么Redis能这么快

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

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

多路I/O复用模型

FD：File Descriptor，文件描述符

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

select监听文件可读可写的情况

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

• 因地制宜（根据不同的操作系统选择不同的函数）
• 优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现
• 以时间复杂度为O(n)的select作为保底
• 基于react设计模式监听I/O事件

二、Redis常用数据类型

供用户使用的数据类型

• String：最基本的数据类型，二进制安全。set name "redis"；get name
• Hash：String元素组成的字典，适合用于存储对象。hmset ZS name "zhangsan" age 20；hget ZS age；hset ZS age 15
• List：列表，按照String元素插入顺序排序。lpush mylist "a"；lpush mylist "b"；lrange mylist 0 10；先输出“b”，后进先出
• Set：String类型的无序集合，通过哈希表实现，不允许重复。sadd myset 1；返回1，再添加sadd myset 1；返回0；smembers myset：查看元素；支持求交、并集
• Sorted Set：通过分数来为集合中的成员进行从小到大的排序，不允许重复，每个元素关联一个double类型的分数。zadd myzset 1 aa；zadd myzset 2 bb；zadd myzset 1 ab；分数可以相同，zrangebyscore myzset 0 10；返回 aa,ab,bb
• 用于计数的HyperLogLog，用于支持存储地理位置信息的Geo

底层数据类型基础

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

三、从海量数据里查询某一固定前缀的key

留意细节

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

使用keys对线上业务的影响

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

dbsize：获取key的数量；keys k1*；返回所有k1开头的key，数量太多时会将客户端卡住一定的时间

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

SCAN cursor [MATCH pattern] [COUNT count]

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

scan 0 match k1* count 10；返回一个游标（表示当前数据迭代到哪里了）和一个数据集（size不一定为10），一次一次的迭代，直到返回的游标为0，即可遍历所有k1开头的key。注：返回的游标不一定是递增的，返回的数据集可能存在重复

四、如何实现分布式锁

分布式锁需要解决的问题

• 互斥性。任意时刻只能有一个客户端获取锁
• 安全性。锁只能被持有该锁的客户端删除，不能被别的客户端删除
• 死锁。获取锁的客户端因为某些原因宕机，不能释放掉该锁，其它客户端再也无法获取该锁
• 容错。当redis的部分节点宕机，客户端仍能正常获取锁和释放锁

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

• 时间复杂度：O(1)
• 返回值：设置成功，返回1；设置失败，返回0；

get locknx；如不存在，则返回(nil)；setnx locknx test；再次设置setnx locknx test02；会返回0，不能被更改。

可通过get locknx；来判断是否有别的线程在使用该锁。

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

EXPIRE key seconds

• 设置key的生存时间，当key过期时（生存时间为0），会被自动删除。
• 缺点：原子性得不到满足。

expire locknx 2；设置locknx的生存时间为3秒。过期之后再设置setnx locknx test02；可成功执行。

当别的线程获取的status为0时，表示有别的现在正在占用资源，会堵塞，直到status为1。风险：redisService.expire()未能成功执行，key一直得不到释放，其它线程一直获取不到key

从redis6.12开始，可使用set命令，即将setnx 和 expire合在一起

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

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

set locktarget 123 ex 10 nx;

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

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

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

五、如何实现异步队列

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

rpush mylist a;rpush mylist b;rpush mylist c; 使用lpop mylist;返回a，lpop mylist;返回b，...

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

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

eg：假设mylist没有值，在客户端1使用blpop mylist 30;会一直等待，直到超时（30秒），在客户端2使用rpush mylist a;客户端2执行成功，客户端1会立刻返回a。blpop能代替sleep做更精准的控制

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

pub/sub：主题订阅者模式

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

eg：在客户端1订阅myTopic：subscribe myTopic；在客户端2也订阅myTopic：subscribe myTopic；在客户端3订阅anotherTopic：subscribe anotherTopic；在客户端4发布消息myTopic：publish myTopic "hello"；此时客户端1和客户端2就会收到myTopic "hello"；在客户端4发布消息anotherTopic：publish anotherTopic "hi"；此时只有客户端3会收到anotherTopic "hi"。

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

解决方案：使用专业的消息队列，如kafka等。

六、持久化方式之RDB

Redis如何做持久化

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

配置文件：redis.conf

save 900 1 （900秒内有一条是写入指令就触发一次快照，即一次备份）

save 300 10 （300秒内写入数或更新数达到10条触发一次快照）

save 60 10000 （60秒内有10000次写入就进行一次备份）

save "" （禁用rdb配置）

stop-writes-on-bgsave-error yes （表示当备份进程出错的时候，主进程就禁止写入新的数据了）

rdbcompression yes （表示备份的时候需要将rdb文件压缩后再保存，建议设置为no，硬盘成本<cpu）

lastsave 返回上一次save的时间点

• save：阻塞redis的服务器进程，直到rdb文件被创建完毕
• bgsave：fork出一个子进程来创建rdb文件，不阻塞服务器进程

可在程序中设置生成带有不同时间戳的rdb文件，以备份不同时间点的数据。

自动触发rdb持久化的方式

• 根据redis.conf配置里的save m n 定时触发（用的是bgsave）
• 主从复制时，主节点自动触发
• 执行Debug Reload的时候
• 执行Shutdown且没有开启AOF持久化

BGSAVE原理

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

Copy-on-Write

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

RDB缺点

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

七、持久化方式之AOF以及混合模式（合成）

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

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

AOF持久化默认是关闭的，需要在配置文件redis.conf中打开

appendonly yes

appendfilename "appendonly.aof"

appendfsync always/everysec/no （always：一旦缓存区的数据有变化就讲数据写入aof文件中；everysec：每隔1秒就将缓存区的数据写入aof文件中；no：屏蔽自动写入aof文件，由操作系统来决定，为了提高效率，操作系统默认会等缓存区填满才讲数据写入aof文件。推荐everysec，默认也是此方式）

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

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

RDB和AOF的优缺点

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

RDB-AOF混合持久化方式

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

八、Pipeline及主从同步

使用Pipeline的好处

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

redis的同步机制

为了提升性能，一般将写操作都放在Master，将读操作都放在Slave

主从同步原理

全同步过程

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

增量同步过程

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

Redis Sentinel

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

• 监控：检查主从服务器是否运行正常
• 提醒：通过API向管理员或其他应用程序发送故障通知
• 自动故障迁移：主从切换（投票协议来决定是否使用自动故障迁移及哪一个从服务器升级为主服务器）

流言协议Gossip

在杂乱无章中寻求一致

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

九、Redis集群

Redis的集群原理

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

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

一致性哈希算法：

对2^32取模，将哈希值空间组织成虚拟的圆环

将数据key使用相同的函数Hash计算出hash值

Node C 宕机

新增服务 Node X

Hash环的数据倾斜问题：

引入虚拟节点解决数据倾斜的问题：（通常将虚拟节点数量设置为32，甚至更大）