Redis拾遗

Posted 2021-01-09 fly-to-the-sky

持久化：

1. RDB：把当前进程数据生成快照保存到硬盘，出发RDB持久化过程分为手动和自动；
   1. 手动触发：
      • save命令，会阻塞当前Redis服务器，知道RDB过程完成为止（基本废弃）
      • bgsave命令，Redis进程执行fork操作创建子进程，RDB持久化由子进程负责。阻塞只发生在fork阶段，时间很短。
   2. 自动触发：
      • 使用save相关配置，会按配置自动触发bgsave
      • 如果从节点执行全量复制，主节点自动执行bgsave并发送给从节点。
      • 执行debug reload重新加载redis时，也会自动触发save操作。
      • 默认情况执行shutdown时，如果没有开启AOF持久化，则自动执行bgsave。
   3. 优点：
      • 压缩紧凑
      • 加速恢复数据远快于AOF
   4. 缺点：
      • 没法实时持久化，bgsave属于重量级操作，成本高
      • 新旧版本兼容问题
2. AOF：以独立日志方式记录每次写命令，重启时重新执行AOF中的命令达到数据恢复，属于持久化的主流方式
   1. 过程：
      1. 所有写入命令都会追加到aof_buf缓冲区内。
      2. AOF缓冲区根据对应的策略向硬盘做同步操作。
      3. 随着AOF文件越来越大，需要定期对AOF文件重写，达到压缩的目的
      4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。
   2. 同步文件策略：everysec（建议的配置）每秒同步一次数据，即使宕机，也会只损失1s的数据。
   3. 重写机制：将超时的命令剔除；无效命令剔除；多条命令合并。降低空间，加速加载。也分自动触发和手动触发。不在此赘述。
　　
3. Redis重启时优先加载AOF如果没有的话加载RDB
4. 问题优化：
   1. fork操作：fork创建子进程会复制父进程的空间内存页表，fork操作的耗时与Redis进程内存息息相关。
   2. 子进程开销优化：CPU密集操作，不要和其他CPU密集服务部署爱一起，造成竞争。避免在大量写入时做子进程重写操作，将导致父进程维护大量页副本，造成内存消耗。
5. 多实例部署：保证机器内每个Redis实例AOF重写串行化执行。

复制：

1. 目的：解决单点问题，满足故障恢复和负载均衡的要求