Redis

一 缓存数据库

1. 作用

实现了对热点数据的高速缓存，提高应用的响应速度，极大缓解后端数据库的压力

2. 主流应用架构
   

3. 缓存中间件

Memcache : 代码层次类似Hash

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

Redis

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

二 Redis

1. Redis为什么能这么快

• 100000+QPS(query per second，每秒内查询次数)

• 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高（单进程单线程模型的key-value数据库，由C语言编写，将数据储存在内存中，不需要I/O）
• 数据结构简单，对数据操作也简单（redis不需要数据之间进行关联）
• 采用单线程（是指主线程是单线程的，主线程包括IO事件的处理，IO对应的相关业务的处理，过期键的处理等等；正因为采用单线程的设计，对于客户端的所有请求，都由一个主线程串行的处理，多个客户端同时对一个键进行写操作的时候，不会有并发的问题，避免了频繁的上下文切换和锁竞争），单线程也能处理高并发请求（借助IO多路复用），多核也可启动多实例
• 使用多路I/O复用模型，非阻塞IO IO多路复用机制详解

Redis采用的I/O多路复用函数：epoll/kqueue/evport/select；如何选择？

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

2. Redis数据类型

• String：最基本的数据类型，二进制安全
• Hash：String元素组成的字典，适合用于存储对象
• List：列表，按照String元素插入顺序排序，先进后出（栈）
• Set：String元素组成的无序集合，通过哈希表实现（添加，删除，查找的复杂度都是 O(1)），不允许重复，可求交集，并集，差集等
• ZSet(Sort Set)：通过分数来为集合中的成员进行从小到大的排序，成员是唯一的,但分数(score)却可以重复
• HyperLogLog：用来做基数（不重复元素个数）统计
• Geo：用于支持存储地理位置信息

3. 从海量Key里查询出某一固定前缀的Key（摸清数据规模）

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

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

Scan cursor [match pattern] [count n]

• 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
• 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
• 不保证每次执行都返回某个给定数量的元素，支持模糊查询
• 返回结果中的游标并不一定是递增的（重复key）

4. 如何通过Redis实现分布式锁

需要解决问题：

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

springboot中redis分布式锁
setnx key value：如果key不存在，则创建并赋值

解决key长期有效

• 设置过期时间

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

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

5. 如何使用Redis做异步队列

使用List作为队列，rpush（在队尾添加）生产消息，lpop（移除并获取列表的第一个元素）消费消息

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

blpop key timeout：阻塞队列直到队列有消息或者超时

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

pub/sub：主题订阅者模式

• 发送者（pub）发送消息，订阅者（sub）接受消息
• 订阅者可以订阅任意数量的频道
• 缺点：消息的发布是无状态的，无法保证可达
• 订阅：subscribe myTopic 发送：publish myTopic “xxx”
  

5. Redis如何做持久化

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

1. redis.conf

• save 900 1 //900秒之内如果有一条是写入指令，就触发产生一次快照
• save 300 10 //300秒之内有10条写入
• save 60 10000 //60秒之内有一万条写入，否则依次往上
• stop-writes-on-bgsave-error yes //当备份进程出错时，主进程就停止接受写入的操作，保证数据的一致性

2. 常用命令

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

3. 自动化触发rdb持久化的方式

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

4. 缺点

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

AOF（Append-Only-File）持久化：保持写状态

1. 特点

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

2. 配置redis.conf

• appendonly yes
• appendfilename “appendonly.aof”
• appendfsync always/everysec/no //写入方式（一旦修改即写入/每一秒/交由操作系统）

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

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

二者对比：

1. RDB:

• 优点：全量数据快照，文件小，恢复快
• 缺点：无法保存最近一次快照之后的数据

2. AOF:

• 优点：可读性高，适合保存增量数据，数据不易丢失
• 缺点：文件体积大，恢复时间长

RDB-AOF混合持久化方式

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

6. Pipeline

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

7. Redis的同步机制

主从同步原理

1. 全同步过程

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

2. 增量同步过程

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

隐患：

• 写操作发生在Master，读操作发生在Master和Slave
• 当Master发生宕机后，将不能进行写操作

8. Redis Sentinel(哨兵)

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

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

留言协议Gossip：在杂乱无章中寻求一致

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

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

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

一致性哈希
一致性哈希算法：

• 对2^32取模，将哈希值空间组织成虚拟的圆环
• 对数据的增减，都只需要修改环空间中的一小部分即可，具有较好的容错性和扩展性
• 缺点：数据倾斜问题，被缓存的对象大部分集中在一台服务机上，引入虚拟节点（将一个服务机的IP加上不同的后缀进行虚拟等等）进行解决