Redis

数据库主流框架

主流框架.png

Redis为何这么快

10000+QPS

传统阻塞IO模型

多路复用IO模型

多路复用的原理

select可监听多个文件描述符，Redis一般采用epoll/kqueue/evport/select

• 因地制宜
• 优先选择时间复杂度为O(1)的多路复用函数作为底层实现
• 以时间复杂度为O(n)的select作为保底,因为select会扫描全部的fd
• 机遇react设计模式监听I/O事件

查询固定前缀的Keys

scan语句.png

Redis实现分布式锁

分布式需要解决的问题

• 互斥性 只有一个客户端可以获取到锁
• 安全性 原子性
• 死锁 不允许发生
• 容错 可以主动释放锁

过期时间

有可能未设置过期时间 程序挂掉,不符合原子性。

符合原子性的操作

实现异步队列

一对一 （一个消费者对一个生产者）

利用List数据结构 RPush作为生产者,LPop/BLPop作为消费者,一个添加数据,一个消耗数据。
但是Lpop不会阻塞,即取即返,利用BLpop可以阻塞,直到有数据才会返回,设置具体阻塞等待时间。

多对一（多个消费者对应一个生产者）pub/sub模式 缺点不保证消息可达,如果客户端下线,服务端发送消息,则再次上线 消息会丢失。

pub/sub模式

持久化 形成快照（Snapshot）

rdb

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

RDB条件

缺点

AOF(Append On File)持久化:保存写指令

aof Rewritting

Redis数据恢复

RDB和AOF都存在的情况,优先加载AOF文件。

优缺点

RDB-AOF混合持久化方式

子进程
1 AOF重写时会从管道读取父进程的增量数据缓存下来,
2 RDB全量保存时也会从管道读取数据
3 不会阻塞
aof文件即由RDB格式的全量数据跟redis操作命令组合而成

PipeLine与主从同步

优点

同步机制

主从同步原理:
1 Master将数据快照发送给Salve,单独抽一个Salve出来做数据规范操作。
2 当Salve加载数据完成后,通知Master,Master会将期间的增量更新再次发送给Slave
3 Salve再次加载完成即视为数据一致
主从同步 不要求数据实时一致,但是会趋于一致

全同步过程:

全同步过程

增量同步过程:

增量同步

Redis Sentinel(主从切换)

主从切换

流言协议 Gossip

Gossip.png

Redis集群

• 一致性算法,对2^32取模,将哈希值空间组织成虚拟圆环(哈希环)
• 将服务器地址或者主机名进行哈希运算,分布在环上
• 将数据的key进行hash定位,顺时针寻找环空间中的服务器
• 容易导致数据倾斜
• 为了解决数据倾斜,引入了虚拟节点,一般一个服务器对应32个节点,甚至更大

存储