好好学 Redis
1. 缓存技术
1.1 主流应用架构
- 缓存穿透
- 熔断
1.2 缓存中间件
1.2.1 Memcache
- 支持简单数据类型
- 不支持持久化存储
- 不支持主从
- 不支持分片
1.2.2 Redis
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
1.3 为什么Redis能这么快？
- 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
- 数据结构简单，对数据操作也简单
- 采用单线程，单线程也能处理高并发请求，多核也可启动多实例
- 使用多路 I/O 复用模型，非阻塞I/O
1.4 多路 I/O 复用模型
传统的阻塞 I/O 模型
Select 系统调用
Redis采用的 I/O 多路复用函数：epoll/kqueue/evport/select
- 因地制宜
- 优先选择时间复杂度为 $O(1)$ 的 I/O 多路复用函数作为底层实现
- 以时间复杂度为 $O(n)$ 的select作为保底
- 基于 react 设计模式监听 I/O 事件
2 Redis的数据类型
3 从海量 key 里查询固定前缀的 key
从一亿条数据里取出拥有固定前缀的10万个 key
- 留意细节
- 摸清数据规模，问清楚边界
KEYS pattern： 查找所有符合给定模式 pattern 的 key： keys + 前缀
keys k1*
- KEYS指令一次性返回所有匹配的 key
- 键的数量过大会使服务卡顿
SCAN cursor [MATCH pattern] [COUNT count]
scan 0 match k1* count 10
- 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
- 以 0 作为游标开始一次新的迭代，直到命令返回 0 完成一次遍历
- 不保证每次执行都返回某个给定数量的元素，支持模糊查询
- 一次返回的数量不可控，只能是大概率符合
count
4 如何通过 Redis 实现分布式锁？
分布式锁需要解决的问题
- 互斥性
- 安全性
- 死锁
- 容错
SETNX key value: 如果 key 不存在，则创建并赋值- 时间复杂度： $O(1)$
- 返回值：成功为 1，失败为 0
如何解决
setnx长期有效的问题expire key seconds: 设置key的生存时间，当key过期时，会被自动删除expire的缺点：原子性得不到满足
set key value [ex seconds] [px milliseconds] [nx|xx]redis 2.6.12之后ex second: 设置键的过期时间为second秒px millisecond: 设置键的过期时间为millisecond毫秒nx: 只在键不存在时，才会对键进行设置操作xx: 只在键存在时，才会对键进行设置操作set操作成功完成时，返回ok，否则返回nil
大量的
key同时过期的注意事项 集中过期，由于清楚大量的key很耗时，会出现短暂的卡顿现象- 解决方案：在设置
key的过期时间的时候，给每个key加上随机值
- 解决方案：在设置
5 如何使用 Redis 做异步队列？
使用 List 作为队列， RPUSH 生产消息， LPOP 消费消息
- 缺点：没有等待队列里有值就直接消费
- 弥补：可以通过在应用层引入
Sleep机制去调用LPOP重试
面试官：如果我不想用 sleep 呢？
BLPOP key [key ...] timeout : 阻塞直到队列有消息或者超时
- 缺点：只能供一个消费者消费
1 | # 等待 testlist 30s 的时间，如果有值就消费 |
pub/sub : 主题订阅者模式
- 发送者 (pub) 发送消息，订阅者 (sub) 接收消息
- 订阅者可以订阅任意数量的频道
- 缺点：消息的发布是无状态的，无法保证可达
6 Redis持久化
RDB持久化：保存某个时间点的全量数据快照
save：阻塞redis的服务器进程，知道rdb文件被创建完毕bgsave：fork处一个子进程来创建rdb文件，不阻塞服务器进程
自动触发 RDB 持久化的方式
- 根据
redis.conf配置里的SAVE m n定时触发(用的是 BGSAVE) - 主从复制时，主节点自动触发
- 执行
debug reload - 执行
shutdown且没有开启AOF持久化
BGSAVE原理
copy-on-write: 写时复制
如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。
缺点
- 内存数据的全量同步，数据量大会由于 I/O 而严重影响性能
- 可能会因为 redis 挂掉而丢失从当前至最后一次快照期间的数据
AOF持久化：保存写状态
- 记录下除了查询意外的所有变更数据库状态的指令
- 以 append 的形式追加保存到 AOF 文件中
日志重写解决 AOF 文件不断增大的问题
- 调用
fork()，创建一个子进程 - 子进程把新的
aof文件写到一个临时文件里，不依赖原来的aof文件 - 主进程只需把新的变动同时写到内存和原来的
aof里 - 主进程获取子进程重写
aof的完成信号，往新aof同步增量变动 - 使用新的
aof文件替换掉旧的aof文件
Redis 数据的恢复
RDB 和 AOF 文件共存情况下的恢复流程
RDB 和 AOF 的优缺点
| RDB | AOF | |
|---|---|---|
| 优点 | 全量数据小，文件小，恢复快 | 可读性高，适合保存增量数据，数据不易丢失 |
| 缺点 | 无法保存最近一次快照之后的数据 | 文件体积大，恢复时间长 |
RDB-AOF 混合持久化
BGSAVE 做镜像全量持久化， AOF 做增量持久化
Pipeline及主从同步
使用Pipeline的好处
- Pipeline与Linux的管道类似
- Redis基于请求/响应模型，单个请求处理需要一一应答
- Pipeline批量执行指令，节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
Redis的同步机制
- 主从、哨兵、集群的配置
一个master用来写，多个slave用来读
全量同步过程
- Salve发送sync命令到Master
- Master启动一个后台进程，将Redis中的数据快照保存到文件中
- Master将保存数据快照期间接收到的写命令缓存起来
- Master完成写文件操作后，将该文件发送给Salve
- 使用新的AOF文件替换掉旧的AOF文件
- Master将这期间收集的增量写命令发送给Salve端
增量同步过程
- Master接收到用户的操作指令，判断是否需要传播到Slave
- 将操作记录追加到AOF文件
- 将操作传播到其他Slave：1 对齐主从库；2 往响应缓存写入指令
- 将缓存中的数据发送给Slave
Redis Sentinel (哨兵)
解决主从同步Master宕机后的主从切换问题：
- 监控：检查主从服务器是否运行正常
- 提醒：通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移：主从切换
流言协议Gossip
在杂乱无章中寻求一致
- 每个节点都随机地与对方通信，最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证消息一定会传递给所有的节点，但是最终会趋于一致
Redis 集群原理
如何从海量数据里快速找到所需？
- 分片：按照某种规则去划分数据，分散存储在多个节点上
- 常规的按照哈希划分无法实现节点的动态增减
一致性哈希算法
对 $2^{32}$ 取模，将哈希值空间组织成虚拟的圆环，可以理解为钟表圆环。
将数据key使用相同的函数Hash计算出哈希值
例如我们有四个服务器，四个服务器Node ABCD在环上的位置如下图所示： 根据我们的一致性Hash算法，数据Object A离Node A最近，所以该数据就会存在Node A上，以此类推。
假设，Node C宕机，此时Node A、B、D并不会受到影响，只有Node C（这里指的是Object C）的对象会重新定位到Node D上。当一台服务器宕机时，受影响的数据，只有该服务器逆时针行走到上一个服务器节点的数据，其它的数据是不会受影响的，而且受影响的数据会存储在该宕机服务器的顺时针行走的下一个服务器上。
新增一台服务器Node X，同上面原理一样。
综上所述，一致性哈希算法对于节点的增减，只需要重新定位环空间中的一小部分数据，具有较好的容错性和扩展性。
但是一致性Hash算法也不是十全十美的。 Hash环的数据倾斜问题： 在服务器节点较少的情况下，容易因为节点分布不均匀而造成数据倾斜问题。
数据倾斜：指的是被缓存的对象，大部分集中缓存在某一台服务器上。
为了解决数据倾斜问题，引入了虚拟节点。
- 虚拟节点：对每一个节点计算多个Hash，计算结果位置都放置一个此服务器位置。
