Redis主从、哨兵、 Cluster集群一锅端

• Redis主从
• Redis哨兵
• Redis Cluster集群
• 公众号：捡田螺的小男孩

1. Redis 主从
面试官经常会问到Redis的高可用。Redis高可用回答包括两个层面，一个就是数据不能丢失，或者说尽量减少丢失;另外一个就是保证Redis服务不中断。

• 对于尽量减少数据丢失，可以通过AOF和RDB保证。
• 对于保证服务不中断的话，Redis就不能单点部署，这时候我们先看下Redis主从。

1.1 Redsi主从概念

• Redis主从模式，就是部署多台Redis服务器，有主库和从库，它们之间通过主从复制，以保证数据副本的一致。
• 主从库之间采用的是读写分离的方式，其中主库负责读操作和写操作，从库则负责读操作。
• 如果Redis主库挂了，切换其中的从库成为主库。

1.2 Redis 主从同步过程

Redis主从同步包括三个阶段。
第一阶段：主从库间建立连接、协商同步。

• 从库向主库发送psync 命令，告诉它要进行数据同步。
• 主库收到 psync 命令后,响应FULLRESYNC命令（它表示第一次复制采用的是全量复制），并带上主库runID和主库目前的复制进度offset。
  第二阶段：主库把数据同步到从库，从库收到数据后，完成本地加载。
• 主库执行bgsave命令，生成RDB文件，接着将文件发给从库。从库接收到RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。
• 主库把数据同步到从库的过程中，新来的写操作，会记录到replication buffer。
  第三阶段，主库把新写的命令，发送到从库。
• 主库完成RDB发送后，会把replication buffer中的修改操作发给从库，从库再重新执行这些操作。这样主从库就实现同步啦。
  1.3 Redis主从的一些注意点
  1.3.1 主从数据不一致
  因为主从复制是异步进行的，如果从库滞后执行，则会导致主从数据不一致。
  主从数据不一致一般有两个原因：
• 主从库网路延迟。
• 从库收到了主从命令，但是它正在执行阻塞性的命令（如hgetall等）。

如何解决主从数据不一致问题呢？

1. 可以换更好的硬件配置，保证网络畅通。
2. 监控主从库间的复制进度

1.3.2 读取过期数据
Redis删除数据有这几种策略：

• 惰性删除：只有当访问一个key时，才会判断该key是否已过期，过期则清除。
• 定期删除：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。
• 主动删除：当前已用内存超过最大限定时，触发主动清理策略。

如果使用Redis版本低于3.2，读从库时，并不会判断数据是否过期，而是会返回过期数据。而3.2 版本后，Redis做了改进，如果读到的数据已经过期了，从库不会删除，却会返回空值，避免了客户端读到过期数据。
因此，在主从Redis模式下，尽量使用 Redis 3.2以上的版本。
1.3.3 一主多从，全量复制时主库压力问题
如果是一主多从模式，从库很多的时候，如果每个从库都要和主库进行全量复制的话，主库的压力是很大的。因为主库fork进程生成RDB，这个fork的过程是会阻塞主线程处理正常请求的。同时，传输大的RDB文件也会占用主库的网络宽带。
可以使用主-从-从模式解决。什么是主从从模式呢？其实就是部署主从集群时，选择硬件网络配置比较好的一个从库，让它跟部分从库再建立主从关系。如图：

1.3.4 主从网络断了怎么办呢？
主从库完成了全量复制后，它们之间会维护一个网络长连接，用于主库后续收到写命令传输到从库，它可以避免频繁建立连接的开销。但是，如果网络断开重连后，是否还需要进行一次全量复制呢？
如果是Redis 2.8之前，从库和主库重连后，确实会再进行一次全量复制，但是这样开销就很大。而Redis 2.8之后做了优化，重连后采用增量复制方式，即把主从库网络断连期间主库收到的写命令，同步给从库。
主从库重连后，就是利用repl_backlog_buffer实现增量复制。
当主从库断开连接后，主库会把断连期间收到的写操作命令，写入replication buffer，同时也会把这些操作命令写入repl_backlog_buffer这个缓冲区。repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

2. Redis哨兵
主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了Redis哨兵机制来解决这个问题。

• 哨兵作用
• 哨兵模式简介
• 哨兵如何判定主库下线