redis的高可用应该包括两个维度 ：

  • 数据尽量少丢失
  • 服务尽量少中断

单机Redis持久化 (数据安全)

持久化类型：1. 快照 2. 日志
持久化的意义：防止冷启动(缓存里没有任何数据，造成雪崩)

快照RDB (默认)

特点：恢复快 (数据io读取与加载)
缺点：缺失比较多(丢失的数据是上次备份到宕机的)

备份：
  • save 在主进程执行，会导致阻塞
  • bgsave fork子进程专门来写rdb
    bgsave时，主进程还可以修改吗？
    主进程可以正常接收请求，但只能处理读操作，不能修改正在执行快照的数据。
    写时复制：这时就会使用操作系统提供的copy-on-write技术，在bgsave的同时，还可以正常处理写操作。
    image.png
    可以1秒1次快照吗？
    不行，因为尽管是bgsave, 但仍有两方面的开销：
  1. 磁盘io频繁，上次没bgsave完成，下一次又来
  2. fork出的子进程越多，主进程被阻塞的可能就越大

日志 AOF

先写内存，再写磁盘。

级别：

  • Always 每操作同步一次磁盘 每操作完整性 (数据完整性好，但性能差)

每个操作指令完成返回前，都要将指令持久化到磁盘，意味着每操作一次都要染指一次磁盘io(flush 缓冲区),性能较差。

  • NO 操作系统缓冲 刷写 (性能佳，但可能丢大量数据)

    一旦宕机，将可能丢失一个缓冲区的数据(8G内存可能丢失1个g, 缓冲区大小由内核参数决定)

  • EverySec 每秒种os缓冲 刷写 (折中，redis默认) image.png

优点：数据保存完整度高
缺点：
1. 慢
2. 冗余量(aba带来的无效更新), redis定期重写(rewrite)，对指令压缩(去掉aba中间的指令)

指令重写(rewrite)

image.png

非阻塞aof重写过程

重写过程是fork出的后台子进程bgrewriteaof来完成的，并不后阻塞主进程。
image.png
aof重写时，redis会执行一个内存copy,用于重写，然后使用两个日志保证在重写过程中，新写的数据不会丢失。

混合模式

使用：
  • 分布式数据结构的redis实例倾向于做数据存储，对数据可靠性要求比较高，使用aof日志
  • 热点缓存数据，特别是时效比较低的热点数据存储实例，使用rdb快照模式。

  • 也可混合使用(仅redis4.x+支持) ，全量备份+增量日志。

    hadoop的 hdfs 就是二者混合使用的思想上的一种高级实现，由fdimage(全量备份)+edits.log(增量备份)组成，如果手上有一个8点的fdimage和8 点以后的edits.log

高可用部署 (服务可靠)

  • 冗余
    • 主主
    • 主从
    • 主备
  • 分治
    • 分片
    • 多实例

Redis主从复制

主从同步过程

https://www.cnblogs.com/cooffeeli/p/redis_master_slave.html

  1. slaveOf masterIp masterPort

redis.conf/从节点启动命令/从节点客户端命令

  1. 建立socket连接
  2. 发送ping命令
  3. 身份验证
  4. 同步

psnc命令，全量+半量同步

  1. 命令传播

主节点有写命令 会传播给从节点
异步传播 会有延迟和数据不一致问题