Redis之分布式解决方案

一、主从复制

目的：容灾（主库所在服务器的硬盘损坏，数据丢失后利用从库恢复数据）

配置：slaveof <master-ip> <master-host> 从服务器会变成只能读，不能写 当redis成为从服务器时，将会清空自身的旧数据 不支持“主主复制”，不能互为slave

复制过程：

　

 

 

快照同步：同步的是rdb文件，很耗费资源。

　　当slave节点第一次加入集群的时候，会发起快照同步。

　　当slave节点落后较多的时候，会发起快照同步。

增量同步：同步是指令流，轻量级。 后续的同步使用增量同步

 

（面试题）Redis-Master的内存无限制会有什么问题？

1.发起快照同步的时候，可能会存在没有内存空间fork子进程。

2.Redis-Master的内存限制建议为物理机的50%-65%。

 

增量同步过程：

　1.主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，异步将 buffer 中的指令同步到从节点。

　2.从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步的偏移量。

内存buffer：定长的环形数组，写满会重头开始覆盖，所有salve共用一个buffer

 

 

（面试题） Redis从库网络状态不佳，会导致什么问题？

1.网络状态不佳导致同步指令流速度慢，进而导致同步速度跟不上buffer的书写速度。

2.buffer中未同步的指令被覆盖，从库只能发起快照同步。

3.全量同步期间，buffer仍然在书写，仍然导致从库还未同步的指令被覆盖，陷入快照同步的死循环。

4. 快照同步是一个很耗费资源的操作，频繁的执行快照同步，严重情况下可能导致会阻塞redis的处理用户请求线程。【1-4是按顺序的连锁产生问题】

解决办法：

　1.根据redis的tps设置合理的buffer缓冲区大小：repl-backlog-size 。

　2.从库和主库最好搭建在同城的不同机房，即保证了冗杂，又一定程度减少了机房间网络连通性不佳的问题。

　3.监控从库日志，若发现频繁发起快照同步，进行告警；必要时下掉有问题的从库。

 

（面试题）Redis从库离线后再上线，一定会触发全量同步吗？

不一定，Redis 2.8+版本，刚加入集群的slave，不是发送SYNC命令，而是发送PSYNC <run-id> <offset>命令，告知master之前同步的主库的run-id以及同步了的offset，主库判断满足如下条件，则使用增量同步：

　1. 从库传递的run-id与master当前的run-id一致（每次redis重启都会更换run-id）

　2.从库传递的offset在环形Buffer中找得到

Redis不能主主复制，但可以从从复制，形成主从链

Redis从库不适合用于读写分离

 

 

二、哨兵模式

哨兵模式：Sentinel，Redis主从模式下的故障切换的解决方案。

目的：当master宕机时可以将slave升级为新的master，从而实现“故障切换(failover)”的目的。

哨兵模式简介：哨兵是一个独立的进程，哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

 

故障转移过程：

  1.主观下线阶段：如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

 

  2.哨兵领导者选举阶段[Raft算法]：

　　1.每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。

　　2.收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。

　　3.如果该Sentinel节点发现自己的票数已经大于等于Max（quorum，sentinels数量/2 + 1）【可以认为半数以上，不含半数】，那么它将成为领导者。

　　4.如果此过程没有选举出领导者，将进入下一次选举。

 

  3.客观下线阶段：将旧master标记为客观下线

 

  4.新master选择阶段：由“哨兵领导者”完成

　　1.过滤不健康的实例

　　2.从副本优先级选择优先级最高的（redis.conf可以配置replica-priority 100）

　　3.若优先级都相同，则选择offset最大的

 

  5.故障转移阶段：由“哨兵领导者”完成

 

 

三、HotKey

（面试题）Redis的热Key可能发生什么问题？会造成什么影响？怎么解决？

　　

热Key：HotKey，指一段时间内被频繁访问的 key。

　某个热门商品

　某个促销活动

　某条热搜新闻

造成的问题：

　　1.热Key过期，缓存击穿，雪崩效应

　　2.热Key导致Redis服务器带宽打满，服务会产生明显的卡顿（集群负载不均）

如何发现HotKey？

　　redis自带工具：redis-cli –hotkeys

解决办法：

　　1.针对可预见的热Key，提前缓存到整个Redis集群上，针对读请求，分摊到各个Redis分片上。（区别于普通的缓存模式）

　　2.针对不可预见的热Key，通过系统自动发现（例如限流10w qps，超过触发告警，告警触发预案），并转换为上述方式。