对初学者十分友好的redis集群详解

主从复制

主从链(拓扑结构、主负责写，从负责读)

画了两张图来帮助理解

 

 

复制模式

• 全量复制：Master 全部同步到 Slave

• 部分复制：（只复制增量 主服务器有8个数据，从服务器有3个数据，只把那5个复制过来）Slave 数据丢失进行备份

问题点

• 同步故障

  • 复制数据延迟(不一致)

  • 读取过期数据(Slave 不能删除数据)

  • 从节点故障

  • 主节点故障

• 配置不一致

  • maxmemory 不一致:丢失数据

  • 优化参数不一致:内存不一致.

• 避免全量复制

  • 选择小主节点(分片)、低峰期间操作.

  • 如果节点运行 id 不匹配(如主节点重启、运行 id 发送变化)，此时要执行全量复制，应该配合哨兵和集群解决.

  • 主从复制挤压缓冲区不足产生的问题(网络中断，部分复制无法满足)，可增大复制缓冲区( rel_backlog_size 参数).

• 复制风暴

哨兵机制

拓扑图（来自网络）

一主二从三哨兵 每一个哨兵都监控着除了自己以外的所有节点

节点下线

• 主观下线

  • 即 Sentinel 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。

  • Sentinel 集群的每一个 Sentinel 节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在 down-after-milliseconds 时间内没有回复 Sentinel 节点的心跳包，则该 Redis 节点被该 Sentinel 节点主观下线。

举个例子：一个烧饼监控着主节点，但是他们之间的网络可能不太好，所以发生了超时，所以这个哨兵就认为这个主节点下线了；第二点很容易理解了，可以理解为redis的ping-pong，你没回应，我就认为你下线了。

• 客观下线

  • 所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum（这是个参数，可以理解为超过总数的一半？） 个统一。

  • 当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要 Sentinel 集群的其他 Sentinel 节点共同判断为主观下线才行。

  • 该 Sentinel 节点会询问其它 Sentinel 节点，如果 Sentinel 集群中超过 quorum 数量的 Sentinel 节点认为该 Redis 节点主观下线，则该 Redis 客观下线。

主观下线是一个哨兵节点认为你下线了，客观下线是所有节点都认为你下线了！！！之所以这样做是为了放在网络波动导致节点下线问题

Leader选举（这个leader哨兵的作用只是用来选出新的Redis Master，选出来以后就恢复平齐地位，原来的master节点恢复正常以后成为新的master的slava）

• 选举出一个 Sentinel 作为 Leader：集群中至少有三个 Sentinel 节点，但只有其中一个节点可完成故障转移.通过以下命令可以进行失败判定或领导者选举。

• 选举流程

  1. 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求设置它为领导者.

  2. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，则同意该请求，否则拒绝。（只同意第一个）

  3. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum（一个参数），则它成为领导者。

  4. 如果此过程有多个 Sentinel 节点成为领导者，则等待一段时间再重新进行选举。