主库同步闪断期间的增量数据到从库
AOF重写缓冲
List
监控
选主
从库1
配置项
6
文件系统本身对文件大小有限制
bgsave子进程
主实例(172.16.19.3)
10
Redis
entry5
写时复制机制保证快照期间数据可修改
哈希表
bgrewriteaof 子进程
key
哨兵
哈希冲突
9
8
每次请求渐进一次如果没有请求Redis会定时执行
PING 命令
整数数组
主线程
entry6
哨兵机制
AOF重写
内存
执行命令写内存
第二次全量快照时的数据
1
双向链表
桶数x2
*next
切片集群来解决大数据量
执行 alaveof 172.16.19.3 6379
entry3
从库
AOF重写机制将大文件重写，通过检查当前键值数据库的键值对，记录最终的状态，多条重复操作压缩成一条，实现压缩AOF文件的大小
5
AOF非阻塞的重写过程
12
Everysec
写操作同步
全局哈希表1
快照是数据能否修改？
*value
记日志到磁盘
可靠性高，数据基本不丢失
4
根据超时判断主从库下线
风险点
Redis数据拷贝
日志
哨兵集群
String
每个写命令都要落盘，性能影响较大
级联的“主-从-从”模式
11
7
3
通知
全局哈希表
阻塞
Redis数据
entry4
Sorted Set
修改
加载repl buffer
1.让从库执行 replicaof，与新主库同步2.通知客户端，与新主库连接
AOF日志记录修改的数据
Set
键值对B
缺点
链式哈希解决哈希冲突
entry1
发送RDB文件
风险
+FULLRESYNC (runId) {offset}
写操作
打分1.优先级最高的从库得高分2.和旧主库同步程度最接近的从库得分高3.ID号小的从库得分高
键值对C
2
磁盘
快照的恢复速度比AOF快，但快照频率不好把握，频率低，容易丢失较多数据，频率高，有额外开销
操作命令
entry2
主观下线
渐进式 rehash
O(n)
快照的问题
闪断
No
主从库及扩展
O(logn)
T1 时刻
宕机
读操作
重写日志
少数服从多数降低误判
同步写回
三种写回策略
主库
执行bgsave生成RDB
全局哈希表2
repl buffer
读取
压缩列表
可以队列缓存再写入
主从库第一次同步流程
优点
保存主节点信息
AOF缓冲
fork
entry
Hash
*key
第一次全量快照时的数据
筛选过滤掉下线，网络总断连等不符合条件的从库
给哪些内存数据做快照？全量 or 部分
第二次拷贝后
跳表
客观下线
操作系统控制的写回
写回时机
清空AOF日志
Redis全局哈希表
第一次拷贝后
性能好
Redis主从库的读写分离
内存快照
客户端
AOF“写后”流程
宕机时丢失数据较多
宕机时丢失1秒内的数据
混合使用AOF日志和内存快照
每秒写回
第一阶段：建立连接，协商同步
清空现有数据加载RDB
从库2
psync ? -1
Redis数据类型和底层数据结构的对应关系
性能适中
横向扩展16384 哈希槽 分布在集群中，扩展或删除后重新分配哈希槽每个redis实例都可以计算数据的在位置
客户端可以通过哨兵的pub/sub订阅主从以及选主的状态
第三阶段：主库发送新命令给从库
解决全量复制和网络传输主库的压力导致不可用的问题
O(1)
写入
Always
第二阶段：主库同步数据给从库
从实例(172.16.19.5)
写时复制
AOF文件过大的影响
简单动态字符串
AOF日志
value
键值对A
追加命令，效率变低
RDB 二进制文件
故障恢复缓慢
主从选择间隙
