《Redis 设计与实现》 读后感
作者: IntoHole | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.buyiker.com/2017/05/19/redis-design-implement-read.html
网址: http://www.buyiker.com/2017/05/19/redis-design-implement-read.html
«Redis 设计与实现» 读后感
- 数据结构篇
第二部分 单机数据库的实现
- 数据库
- 过期键删除的策略
- 定时删除：设置timer函数，设置过期时间后，对数据进行删除，虽然对数据库的体积控制最好，但是占用大量cpu时间
- 惰性删除：只有再次访问数据的时候，通过判断是否已经失效，如果失效，调用函数删除key，但缺点如果没有再次访问，数据会积累；
- 定期删除：建立定时任务，扫描整个数据库的数据键，判断是否为失效；如果为失效则删除；删除太频繁，占用cpu；删除时间太长，则浪费内存（数据体积增大）
- redis使用的是：惰性删除和定期删除；
- 持久化对过期键处理策略
- 同步到磁盘中的时候，会判断键是否已经过期，过期则不保留
- 从磁盘中载入的时候，判断键是否已经过期，过期则不载入
- 同步删除键
- 从server显示的发出DEL命令，同步从服务器中，从服务器只有接收到主服务器删除命令，才会删除，否则，读取数据正常
- 过期键删除的策略
- 持久化
- RDB持久化
- 保存redis储存数据的信息
- SAVE:持久化过程是阻塞主线程，redis无法正常提供服务
- BGSAVE:fork主进程，将redis内容直接保存在磁盘中，redis可正常提供服务，这样做有两个缺点；内存double；数据很容易不同步
-
优先级小于AOF文件，如果存在AOF文件，优先从AOF载入
-
save 900 1 // 如果服务器在900秒内，处理一条以上数据，触发save命令 save 300 10 // 服务器300秒内，处理10条以上数据，触发save命令 save 60 10000 //上面保存多个配置数据，redis间隔时间循环判断是否需要保存 struct redisServer { // 从上一次save命令发生后，总共的操作次数 long long dirty; // 最近一次保存的时间 time_t lastsave; } - RDB文件结构部分
- AOF持久化
- 保存redis所执行的写命令操作
- 同步方式：
- 追加(append)
- 文件写入
- 文件同步(sync)
- 将命令写入一个aof_buf缓存区,转换为协议格式，存入缓存区;
-
appendfync选项不同含义
appendfync 选项的值 flushAppendOnlyFile函数的行为 安全度 always 将aof_buf缓存区的所有内容写入实时同步到AOF文件中 高，但带来大量系统频繁写入磁盘操作 everysec 有独立线程，判断两次同步操作是否超过1秒钟，如果超过启动同步操作 中等 no 将aof_buf缓存去的所有内容写入同步文件，但不进行同步操作，何时同步交给系统来做 低，如果系统宕机；缓存的内容将丢失 - 重载AOF文件过程，redis建立一个虚拟的客户端，将AOF命令解析出来，通过虚拟客户端执行；
- AOF重写功能；消除老AOF中过期命令，达到AOF文件瘦身的功能
- RDB持久化
- 事件
- 系统解耦通过消息机制实现，上面无需管下面实现思路，但是提供了一个可以相应的消息
- 文件事件
多机数据库的实现
- 复制
-
SLAVEOF IP PORT // 将本redis作为IP:PORT redis从服务器 // 主从通过消息将所有操作同步 - 旧版复制功能
- 同步
- 从服务器发送SYNC命令；主服务器执行BGSAVE命令，生成RDB文件,主服务器将RDB文件发送给从服务器；从服务器通过加载RDB文件，达到与主服务器状态一致的状态;
- 主服务器将缓存区内的写操作命令，发送给从服务器中，将主服务器的操作同步给从服务器状态
- 命令传播
- 主服务器将自己执行的命令，发送给从服务器执行，达到数据库的一致性；另外，忽略命令同步操作中间段的不一致性
- 缺陷
- 断线重连的时候，需要执行整个上述两步骤，造成资源极度浪费（同步RDB文件，会造成主服务器CPU／IO／网络带宽）
- 同步
- 新版复制功能
- 同步
- 初次同步的时候，跟旧版一致，都是通过RDB文件，将整个数据库同步给从服务器的；
- 断线重连部分，只将该期间主服务器的写命令同步给从服务器，进行状态一致操作就可以了
- 部分重同步实现思路
- 复制偏移量
- 主服务器向从服务器发送N个字节数据的时候，就将自己的复制偏移量加上N
- 从服务器接收到N个字节数据，将自己复制偏移量加上N
- 主从服务器通过对比复制偏移量大小，就可以知道是否状态一致；如果从服务器保持不一致的时候，只需要主服务器将不同偏移量不同的写命令数据，再次同步给从服务器就可以了
- 复制积压缓存区
- 固定大小FIFO队列,先进入队列中的命令，如果队列已经满了，则进行丢弃操作；
- 设置大小公式：断线后从服务器链接主服务器平均时间 * 每秒钟进行写操作的大小
- 复制策略（发现主从不一致，复制偏移量不一致）
- 如果未同步主服务器的命令还存在复制缓存区内，执行从服务器未同步的命令行；
- 如果未同步主服务器的命令不存在复制缓存区内，则执行完整的重同步操作
- 复制策略（主服务器发生变更）
- redis主从都会有一个40位(数字、字母组合)大小ID，主从都会保留彼此ID
- 如果从服务器发生主从不一致的情况的时候，如果保存的主机一致，主服务器执行部分重同步操作
- 如果从服务器发生主从不一致的情况的时候，如果保存主机ID不一致，则执行完整重同步操作
- 复制偏移量
- 同步
-
