数据库主流框架
主流框架.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个节点,甚至更大
存储
